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

Hi Martin,

Thanks for your efforts on this topic.

On Wed, Jul 31, 2002 at 08:53:15PM +0200, Martin Matula wrote:
> 3) create new XMIReader interface - this interface will inherit from 
> org.xml.sax.ContentHandler

Why then is their a method XMIReader.read(InputSource) ?

As I understand the usual design of XML interfaces it should be done
this way:

/**
 *  Instances of classes implementing this interfaces are supposed
 *  to be used in the following way:
 *  <pre>
 *   XMLReader.parser = XMLReaderFactory.createXMLReader();
 *   parser.setContentHandler(xmiReader);
 *   parser.parse(inputSource); 
 *
 */
public interface XMIReader extends ContentHandler, Cloneable {
  ... additional interface methods but no read method ...
}

Having the read(..) method in the interface gives a misleading hint to
implementors that they are free to implement read(..) as they
like. But if this would be the case a user would be forced to choose:
Shall I use the instance of XMIReader I have at hand as ContentHandler
(see the javadoc above) or directly via read(..). This is ugly, because
the user has no clue what the difference is.  Hence I would recommend
either to remove read (the preferred solution), or at least to
document that read(..) is simply a convenience for the user and *must*
be implemented in a way semantically equivalent to the code given in
the Javadoc above.

Why do you allow to define a collection of extents whereto to write ?
Do you suppose that a XMIReader should write simultaneously to all
those extents ? I yes, I think that should be documented in the interface.

> 4) create new XMIWriter interface - write method of this interface will 
> take ContentHandler as one of its parameters

Here I similarily do not understand why a ContentHandler is one of the
parameters no the only one:

public interface XMIWriter {
  .. additional parameters but no further write method ..
  
  /**
   * To write to a stream or other kind of output target user
   * can use code like:
   *
   * <pre>
   * Writer writer = ... ;
   * ContentHandler handler = new com.megginson.sax.XMLWriter(writer);
   * xmiWriter.write(handler);
   * </pre>
   *
   * <code>XMLWriter</code> is in the public domain and can be downloaded
   * from <a href="http://www.megginson.com/Software/">here</a>.
   */
  public void write(ContentHandler handler);

}

Having written this I now understand that you need the document URI to
be able to support the XMIReferenceProvider. OK, so why not simply
allow the document URI as optional second parameter of write.(..).

> 4) one can chain XMIReader and XMIWriter. The simplest example would be 
> to chain them directly which enables copying from one extent to another:
> xmiWriter.write(<myOutputTarget>, xmiReader);

Yes ! And the nice thing is, that this should even be quite
performant, because neither serialization nor parsing must be
performed !

> - XMIHRefResolver.resolve now receives also a pointer to XMIReader. This 
> is to make it possible for the resolver to clone the instance of 
> XMIReader (this will make a new copy with preserved properties and 
> extents) and read a new XMI file if necessary.

Read the new XMI file into which extent(s) ?

Do circular references between XMI files pose problems ?

If the XMIHRefResolver shall be able to open a new XMI file and if the
URI of the new XMI file is given relatively to the original one, it
must know the URI of the original XMI file. But the XMIReader may be
used as ContentHandler and, as such, it does not in every case know
about the URI, because XML parsers are not forced to call
ContentHandler.setDocumentLocator(Locator). A solution would be to
document, that references given by relative URI's may be resolved only
if ContentHandler.setDocumentLocator(Locator) is called.

-- 
Holger Krug
[email protected]