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

Re: RFC: Simple XML Event-Based API for Java

• From: "Simeon Simeonov" <simeons@a...>
• To: "xml-dev Mailing List" <xml-dev@i...>
• Date: Wed, 17 Dec 1997 16:37:35 -0500

A few comments related to a few posts:

I. Multiplicity of Application - Processor relationship

The "one app, multiple processors argument" is not convincing in my opinion:
(a) I don't think this use of the simple API would be common, and (b) it is
trivial to implement a solution that does this outside the API. I feel the
same about the argument "one processor, multiple applications".

If we make the multiplicity of the relationship between XmlApplication and
XmlProcessor 1 to 1 we can eliminate the XmlProcessor arguments to
XmlApplication methods AND the get/set methods for user data in
XmlProcessor. Additionally, we won't need both addApplication() and
removeApplication().

I see the removal of at least three methods in XmlProcessor and the removal
of XmlProcessor as an argument to XmlApplication methods a substantial gain
for the simple API. Further, I'll get immense personal satisfaction from
seeing the handling of arbitrary user data removed from XMLProcessor.

II. Positional information

I'm somewhat surprised that parser writers claim it is difficult to extract
information about the positions of elements in an XML document. Can s.o.
explain why this is the case? In my work with markup languages I've always
represented the position of elements with a pair of (offset in data stream,
line number, column number) triplets. Providing this information will
certainly result in slightly lower performance, but the functionality it
enables for editing, good error reporting and validation is significant.

III. Exceptions

I am uncertain about the implications of exceptions leaving either the
XmlProcessor or the XmlApplication objects. In particular, I am wondering
what would happen if the XmlProcessor and XmlApplication are used as beans.
I know that in the COM/CORBA world this is very undesirable.

In general, I think it leads to a more complicated programming mechanism.
S.o. mentioned that stopping the parse is difficult with top-down parsers.
While this is true in principle, I there are some very simple mechanisms for
stopping a top-down parse. I'd be happy to discuss these with whoever is
interested.

IV. IDL

I did try a number of times to bring up the issue of a language independent
API with little success. I do see the benefit of something being done with
Java right now, so I'll just wait for the Java API to stabilize before
looking at ways to express it in IDL.

Regards,

Simeon Simeonov
Allaire


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

• Prev by Date: Re: inclusions/exclusions/named groups
• Next by Date: Re: inclusions/exclusions/named groups
• Previous by thread: Re: RFC: Simple XML Event-Based API for Java
• Next by thread: Re: RFC: Simple XML Event-Based API for Java
• Index(es):
  • Date
  • Thread