Re: PROPOSAL (round 3): Extensions to MDR XMI API

Hi Martin,

Martin Matula wrote:
> Brian,
> I looked at jaxp transform API and it seems to me that it would be much 
> better to provide XMIContentHandler (implementing ContentHandler - would 
> implement reading of XMI documents) and XMIProducer (implementing 
> XMLReader) - this way the user will be able to create SAXSource easily 
> by passing XMIProducer as XMLReader to the constructor, which is exactly 
> what you want to do 

I was supposing that the InputSource used for the SAXSource (and thus 
the parameter to XMIProducer.parse()) would be an 
"XmiRepositoryInputSource" that held the extent/collection of objects 
being serialized. The XMIProducer (XMLReader) implementation would not 
need to maintain any state so, it could be used in multiple threads 
concurrently, etc. Thus, one XMIProducer could parse many 
XmiInputSources, even simultaneously. And I was expecting that this 
XmiRepositoryInputSource/XmiProducer pair would be hidden behind the 
SAXSource and thus not appear in the API, making the API 
smaller/simpler. In particular, it might be better to implement the 
input source with two classes (one for writing a whole extent, and one 
for writing a collection of objects).

 > (you don't want to have factory for XMISAXSource,
 > because the only thing that would make it [XMI]SAXSource would be a
 > specific implementation of XMLReader in its XMLReader property. But it
 > does not make it obvious that if somebody changes this property, the
 > "XMI" in the SAXSource's name is in fact gone).

Sure, but I didn't have any XMISAXSource class/interface in the 
proposal; I was using the JAXP SaxSource/SaxResult directly. I don't 
even think that an XMISAXSource/XMISAXResult class would be needed in 
the implementation (exposed in the API or not). By contrast, I think 
that an XmiRepositoryInputSource and XmiRepositoryReader (XMLReader) 
would be necessary for the implementation but not for the API. The issue 
would be what to do if a combination (XmiRepositoryInputSource, 
non-XmiRepositoryReader) or (non-XmiRepositoryInputSource, 
XmiRepositoryReader) is provided. I was just planning to document that 
the inputSource and xmlReader properties of the SAXSource should not be 
modified (this could be enforced by an XMISAXSource implementation class 
I suppose).

> The same holds for SAXResult, where XMIContentHandler can be passed to 
> the constructor.

Similarly, I felt that the XMIContentHandler would be not necessary to 
be in the API if I used SAXResult directly. The use case provided for 
having SAX events revolved around transformations. In particular, Holger 
mentioned Apache Cocoon which seems to integrate directly with JAXP/TrAX 
(from cursory insepction of the documentation). So, my intention was to 
make the use of transformations as simple as possible for the user while 
also conforming to the JAXP API, which I just read about over this 
weekend after reading Libor's post. Libor has "NetBeans/Sun 
Microsystems, XML Project" in his signature so perhaps he could point 
out what would be best for intregrating the MDR XMI stuff with the rest 
of the NetBeans XML infrastructure for the future.

Anway, I do see that an advantage of using XMIContentHandler and 
XMIProducer would be that direct dependencies on JAXP's 
javax.xml.transform API would be eliminated. Is some usage scenerio 
where SAXResult/SAXSource would be less convenient to use than 
XMIProducer/XMIContentHandler? Or is it just a trade-off between (user 
convenience + fewer API classes) and eliminating the direct TrAX dependency?

- Brian