[
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
***************************************************************************
|