xml-dev - Re: SAX Level 2 (was 1998-04-20 Pre-Release...)

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

At 10:17 23/04/98 -0400, Ray Cromwell wrote:
>Hi, I've been a lurker on this list for awhile, but I thought
>I'd add my two cents.

Thanks very much Ray. 

>
>I identify with the need to keep SAX simple, but only because it helps
>rapid adoption in the beginning in order to make it a defacto standard
>(because it is easy for parser writers to implement).  A huge interface
>like JDBC would take an effort that many freeware authors wouldn't
>embark on. So I think David has done Java/XML programmers a wonderful
>service by organizing the effort.

Fully agreed. I think that questions came up during the SAX process that
no-one had anticipated at the start. I suspect that most people (like me)
thought that SAX would be a 'simple' subset of the DOM and that the main
effort was to determine where the cut would be.
 
>
>
>However, I think there is a need for a ubiquitous, parser independent,
>API that gives one complete control over their data structures, but
>without any (or negligable) information loss. Larry Wall gave a
>convincing presentation at XML98 as to how Perl will support XML which
>made my mouth drool compared to the level of information I'm getting
>now. In fact, I built my application around Lark instead of SAX because
>I needed access to location offset information.

I think others have answered this - the DOM is intended to represent the
document without significant loss. [There may be discussion about the exact
lexical input - e.g. was LF or CRLF used, etc.] The SAX experience has
shown - I think - that a lot of issues get raised for the first time during
the design process - such as exceptions and characters - and hopefully this
will ease the DOM's creation.  

I agree fully with David that we shouldn't try to converge on where the DOM
will develop to.

It's worth noting that SAX makes things *enormously* easier for most
application-writers. Yes, there may be some information loss, but many
applications simply want to use the 'content' of the document. In those
cases only about 5 methods are required. And I will certainly sleep happier
knowing that the problems of Locale, etc. have been addressed even though I
doubt I shall need them personally.
>
>There are a whole class of applications that are impossible to write
>with SAX, namely, authoring tools, or any tools that need two-way
>manipulation. Another class of applications need access to DTD
>information.

Yes. SAX was never intended to support the full power of authoring tools.

>
>Right now, it seems only IBM's XML for Java supports access to the DTD,
>however, it does not give location offset information. Thus, it's
>looking more and more like parser features are going to diverge, which
>means SAX has two possible future scenarios:

An exciting aspect of XML is that we move into new territory. How DTDs will
be used will depend on the coming generation of XML authors. For some
applications they are critical - for others there may be de facto
approaches which avoid needing them. [Example. If everyone restricts the
use of attname ID to refer to attributes of type ID, then even without the
DTD this (implied) semantics might be supported by a wide range of tools.
Some will find this horrible, others will see it as natural - applications
will have to add lots of other semantics.]

>
[...]

>Ok, now that I've started a flame war and gotten that off my chest :),
>I'd like to nominate the three biggest features I'd like in SAX Level 2
>(or SAX2.0), in order of importance.

No you haven't :-)  We don't have flame wars on XML-DEV. If a topic looks
like addressing a critical point we try to work out what needs to be done
and whether XML-DEV is the right place for 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)