Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2 Event Sequence [Was: Re: SAX2: relative orderingofstartDocument
 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html *************************************************************************** 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
