xml-dev - Re: Failure Criteria: Simple XML Event-Based API for Java

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

We are in danger of losing focus, yet again.  I am sure that recent
postings are valuable, but some of the visions are *way* beyond where we
started from. I do not believe that we need a byte-for-byte transformation
of XML documents, with all the CDATA sections, comments, parameter entities
and goodness knows what else preserved. I don't think that TimB and DavidM
envisaged this at the start either.

I believe it is important that we make progress on this - see below.

We have just about got critical mass on this if we buckle down. 

There are two sorts of posting on this subject: those people who have
offered to *do* something; and those people who have offered to tell the
others what to do :-). These are all of equal value, but some are more
equal than others towards getting the project finished. 

[Tim Bray - ca 1997-12-12]

>I agree with Peter that we should just buckle down and get on with what used
>to be known as XAPI.  

Unless anything fundamental has changed I am still acting on this supposition.
I have made what I hope is a constructive suggestion by offering to work
with *whatever* comes out of the project. I am deliberately keeping quiet
in public on the technical aspects of the interface.

At 09:42 17/12/97 -0500, David Megginson wrote:
>Peter Murray-Rust writes:
>
> > Yes.  Let's please get this bus into the air. If it needs tweaking
> > or junking later, it's not the end of the world :-). I couldn't
> > bear it if we go down the same road as we have done 2-3 times
> > before, drawing out the process and finally running out of steam.
>
>Any project should have measurable failure criteria.  Here are my
>suggestions.
>
>The Simple XML Event-Based API initiative will have failed if either
>of the following is true:
>
>1) By Monday 12 January 1998, at least three Java parser writers have
>   not agreed to support a specific set of common interfaces.

My understanding is that TimB and DavidM are on board, We also have an
offer from Gavin Nicol to turn the result into an IDL.

>
>2) By Monday 12 January 1998, at least three Java applet or
>   application authors have not agreed to use the same set of common
>   interfaces that the parser writers have agreed to support.
>

MONDO and JUMBO have publicly offered and - forgive me, but without the
hypermail I can't find it - another offer of a collaboration.

We would be delighted to have other people involved. I suggest that in
further postings you think "how can I help the project in a practical sense?"

Reasons for SAX-J
-----------------

I am very clear that there is a need for SAX-IDL and SAX-J. [If you also
feel this, and feel that you can help the project, it would be useful to
give additional positive reasons.]

I do not know how many people have worked with more than one XML parser,
but if  you haven't take it on trust that the interfaces - though
professionally written - that are provided are sufficiently different to
cause a lot of confusion and unnecessary work. It's not trivial to find out
the structures that each return, nor necessarily the detailed syntax.
[Example - what is the structure of a PI? A string,? 2 strings? a string +
nameValuePair*? a string which includes the <?...?>?, etc.] What is an
Entity and how many different sorts are there? 

The consequence of this is that most people will probably start with one
parser and stick with it. The problem with this is that most parsers at
present have (a) bugs and (b) features. Example:
<!DOCTYPE CML SYSTEM "cml.dtd">
What does the parser do if (a) cml.dtd exists? (b) cml.dtd exists but does
not contain an element CML (c) exists but is broken (d) does not exist.
[This may not be covered by the proposed API, but it's typical of the
*many* unresolved problems that parser-writers have to face and where
different ones have different behaviours.] I know that some people think
that XML shouldn't control anything at this level ("it's up to the
application"). That's a valid view but not everyone thinks that way and
some of us need some more communality.

In this way we shall get parser-application combinations which do not
interoperate.  In a mature XML world this isn't a problem, but at this
stage there is a lot that we have yet to learn about how XML works. So I
believe it's critical to define what comes out of a parser, and SAX is the
most immediate way of doing this. As far as I know no-one has even compared
the output of different parsers to see whether they are consistent. [JUMBO
does this, but in pictorial form].

An underlying objection is that "we should simply wait for the DOM". I
don't know how far away this is, but (a) by that time we shall have a
variety of incompatible parsers and (b) if recent postings here are
relevant to the DOM there will be considerable discussion about what should
be in it.  I also believe that for many applications the DOM is
inappropriate, being too complicated for what many people need. 

In my naivety I thought there was value in a "Simple" interface - i.e. one
which wasn't complicated. The advantage of this is that newcomers to XML
could use it before moving on to more complex applications. "Simple" seems
to have mutated into "elementary", as in "elementary particle". My feeling
was that Lark, AElfred, et al are all - at present - simpler than the DOM
and that they represented a rough communality of a greater degree of
simplicity. In recent postings nobody seems to think there is a need for a
less complex interface - the general impression is that "it's not worth
doing anything for the DPH because they won't want anything we give them."
I'd disagree, and maybe if no-one else does it it will emerge out of the
present exercise.

-----------------

I appreciate that it's difficult to home in on exactly what subset of
functionality is required in SAX, but this now has to be left to the people
actually working on it.  

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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