[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Xapi-J: proposed interface to Document

• From: jtigue@d... (John Tigue)
• To: xml-dev@i...
• Date: Sat, 19 Jul 1997 22:04:02 -0700

I would like to propose an addition to Xapi-J which would be the start
of the interface to a document.

The current definition of Xapi-J focuses on the interface IXMLProcessor
and its method readXML() which returns a reference to an IElement which
represents the root element of the processed document. This choice was
made simply because it reflected the lowest common denominator of the
currently available XML processors. The results are proving to be
awkward.

For example, a processor might construct a representation of the entire
document including any internal DTD. As Xapi-J currently stands, the DTD
representation would not be accessible because only the root element is
returned from readXML() rather than a reference to the entire document.

Perhaps it would be better to return a reference to the document. The
root would then be available through, say, IDocument.getRoot(). As such
I would like to propose the following beginning to IDocument:

package xml;

public interface IDocument
    {
    public IElement getRoot();
    }

Obviously this definition of IDocument is incomplete. The benefit is
that the underlying implementor of IXMLProcessor could do whatever other
work it does, attaching references to those results to the IDocument
which it would return to the processor client. An Xapi-J client could
simply call getRoot() to get the root element (with everything else
behaving just as it did before IDocument was added to Xapi-J). Clients
knowing more about what a particular implementor of IXMLProcessor does
(and returns) would be able to cast the returned IDocument reference to
a specific class in order to access any additional information attached
to the IDocument.

Although this definition of IDocument is not complete, I can think of no
better choice. Also, as Xapi-J gets kicked around more, IDocument would
probably be defined in more detail making it more useful. For example,
IDocument should probably implement IContainer, there should be a way of
accessing the DTD information, etc. For now this IDocument allows Xapi-J
to move beyond one of its current problems.

Several current XML processors have a document class which could easily
implement IDocument. For those which don't have a document class but do
produce representations of the element tree, adding a new class which
implements IDocument, as shown above, would be trivial.




--
John Tigue
Programmer
jtigue@d...
DataChannel (http://www.datachannel.com)
206-462-1999



xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@i... the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@i...)

• Follow-Ups:
  • Re: Xapi-J: proposed interface to Document
    • From: Richard Light <richard@l...>

• Prev by Date: Chief Technology Officer Position - XML Knowledge Needed
• Next by Date: (ISOdia, ISOtech, etc explained)
• Previous by thread: Chief Technology Officer Position - XML Knowledge Needed
• Next by thread: Re: Xapi-J: proposed interface to Document
• Index(es):
  • Date
  • Thread