OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX2: relative ordering of startDocument() & startDTD() events?

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <david-b@pacbell.net>
  • To: David Megginson <david@megginson.com>
  • Date: Tue, 08 Feb 2000 18:42:30 -0800

David Megginson wrote:
> Michael Fuller <msf@io.mds.rmit.edu.au> writes:
> > > If not, what sensible reporting scheme exists
> > > for stuff like
> > >
> > >     <!ELEMENT foo (%pe1;|%pe2;|foo)*>
> >
> > Urp.
> I'm afraid that my answer to that is "who cares?"  

Keeping in mind that the most common example of this problem is

    <element attribute="some &entity; &references; are here"/>

I'd think basically anyone actually trying to use the start/end entity
callbacks would conclude that they just can't work.

The current level of reliably conveyed information is barely more than
a single "includedEntity (String name)" callback, but the latter is
at least not being deceptive about handling entities used to build any
markup constructs that have specialized callbacks.

>	It's not that DTDs
> aren't useful (I use them every day), but that I don't see that the
> demand for a generic DTD interface with that level of detail is really
> going to be that significant even in the medium term -- it's not
> something that most applications need.

The problem isn't specific to DTDs.

> > > Rather than provide multiple parser-dependent interpretations of those
> > > calls, or trying to make them all fit into the same non-standard mold, I
> > > just removed essentially all that support.
> >
> > Yep; looks like maybe we do need an explicit SAX data model...
> > nothing fancy, just an itemization of the events, their ordering,
> > their relationship to each other and the document context.
> That's a little tricky, because it has to be done incrementally:
> people will define new hander types all the time, and DeclHandler and
> LexicalHandler themselves are not core handlers like ContentHandler.

Part of defining any new event is explaining where it's signaled with
respect to other related events.  Without knowing that answer for the
entity expansions, that data is useless.

For entity expansion reports to be useful, they would need to be at
the level of grammatical tokens ... rather than the production level
data provided elsewhere in SAX.

- Dave


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS