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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: SAX2 Event Sequence [Was: Re: SAX2: relative orderingofstartDocument

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <david-b@pacbell.net>
  • To: Michael Fuller <msf@io.mds.rmit.edu.au>
  • Date: Mon, 28 Feb 2000 16:17:31 -0800

Michael Fuller wrote:
> 
> Thanks for the corrections, David; folded in at:
>     http://www.mds.rmit.edu.au/~msf/misc/SAXEvents.html

Great!  I'm only responding to a couple points here.  Turns out
they're interrelated.


> DavidB> I have a few questions/comments:
> 
> DavidB> - It's established (yes?) that everything outside the
> DavidB>   DTDEvents will be in lexical order.  Is that also required to
> DavidB>   be true for DTD events?  (I got no answer when I asked this
> DavidB>   question before.  Near as I can tell nobody else has
> DavidB>   implemented LexicalHandler/DeclHandler, so nobody else has
> DavidB>   needed to care.)
> 
> I'm not sure if that's the case.

Good!


>	 I've partially wrapped SP and (without
> actually checking ;-), I've got a funny feeling that it may not always
> report DTD events in lexical order. Regardless, given that a DTD is loosely
> unordered (other than needing to define entities before their use), is there
> any useful reason to constrain parsers to a lexical ordering of DTD events?

If you dig up the original note I sent, you'll see three
different orders I'm now seeing.  I'd be a bit surprised
if your partially wrapped SP did one of those ... unless
it were lexical order!  :-)

The reason to specify would basically be so that folk can
recreate DTDs in some useful form -- including having any
start/end PE events making sense (see later).

On the other hand, I'd be equally happy if the specification
was explicit that only a minimal ordering requirement
(as you noted) existe.  But if it does so, it should also
be explicit that PEs are never reported with start/end entity
callbacks.

The real problem is IMHO that this is unspecified.  Until it's
specified I don't know if I've got to fix a bug in one parser.


> DavidB> Also, I was under the understanding that startEntity/endEntity
> DavidB> would not appear within DTDEvents ...
> 
> Ah, you're right, I think.  'startEntity()' is defined as:
>     "Report the beginning of an entity in content."
> (fix applied.)
> 
> I guess "in content" actually means "in element content";
> if so, that excludes its occurrence w/i DTD events.

But one part of the spec (before the missing end tag ;-) says
element content, and another (after) talks about PE callbacks;
as does another part.  It's internally inconsistent on that
point.  (My soon-to-be-distributed version resolves those in
the way I thought had been agreed on xml-dev...)


> Question: is there reason to restrict startEntity()/endEntity() to document
> content use only, or would it be useful to allow parsers to (optionally)
> report them w/i DTD content? Not a very important issue, I admit; I suspect
> that most current parsers don't do this, so probably better to leave things
> as they are.

Again, I don't have any problem _allowing_ a parser to do something
that's sensible (e.g. report a subset of start/end entity events
for PEs in places that might make sense.  But I've got a problem
with a spec that's telling users that my parser(s) can do things
that are at best nonsensical.

That is, this gets back to the lexical-ordering issue above ... since
the start/end PE events only really seem to make sense as ways to partially
reconstruct the literal input.

- Dave

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************




 

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

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