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

Hi Martin,

Martin Matula wrote:
 > Brian Smith wrote:
 >
 >>     * An open issue is how to deal with the XMIReferenceResolver
 >>       callback that was in XMIReader. If a callback-style interface

 > If it would be possible to do a non-callback approach, we would do it.
 > We haven't found out how to do it in this case. Otherwise we would of
 > course do it without the callback.

I'm not sure how to do it. It does seem like there needs to be one 
XMIReferenceResolver created each time a document is read: 
XMIReferenceResolver is stateful and so it can't be used by multiple 
threads concurrently. Also there is no way to reset the reference 
resolver to its initial state, so it can't be used on multiple documents 
even in a serialized manner. I know that some people want to create stub 
objects using custom ReferenceProviders. What other usage scenerios are 
there for XMIReferenceProvider, besides resolving relative URI's (which 
could maybe be done by javax.xml.transform.URIResolver)?

If XMIReferenceResolver must exist and it must be stateful, perhaps it 
could maintain all of the per-document state for the 
XmiReader/XmiSAXSourceFactory, making XmiReader implementations 
potentially stateless?

 > The second issue is, how the reference resolver can create a new
 > instance of the reader with the same configuration to be able to
 > resolve external references.

Sure, I was thinking that the XmiReaderConfiguration would be passed to
the reference provider as a paramter to resolve() instead of the
XMIReader. That would be needed anyway since XmiSAXSourceFactory would
not have an XMIReader instance to pass anyway. I was thinking that once 
configured, an 
XMIReader/XMIWriter/XmiSAXSourceFactory/XmiSAXResultFactory's 
configuration would be immutable (again, for mutithreading/recycling 
reasons), but I'm not sure of the best way to enforce that in the API.

 > Also there is no way to specify a document URI in XmiWriter.write,
 > which is essential for reference resolver to work.

I assume that you are talking about the reference provider, and you are
right. It seems we are all overlooked that when we decided that
XMIWriter wasn't necessary. The easiest way to fix it would be to say
that reference providers can only be used with the SAXSource/SAXResult
classes and not with XmiWriter. Otherwise, XMIWriter would have to still
exist with the extra write() methods, and XMIWriterFactory would return
XMIWriters instead of XmiWriters.

- Brian