[
Lists Home |
Date Index |
Thread Index
]
- From: David Brownell <david-b@pacbell.net>
- To: Michael Fuller <msf@io.mds.rmit.edu.au>, David Megginson <david@megginson.com>
- Date: Mon, 28 Feb 2000 13:14:32 -0800
Michael Fuller wrote:
>
> [As promised sometime ago, a summary of the SAX2 event sequence.]
Looks like a good summary -- thanks for drafting this!
I have a few questions/comments:
- It's established (yes?) that everything outside the
DTDEvents will be in lexical order. Is that also
required to be true for DTD events? (I got no answer
when I asked this question before. Near as I can tell
nobody else has implemented LexicalHandler/DeclHandler,
so nobody else has needed to care.)
- There's a missing "setDocumentLocator" call before
the startDocument one; it's optional, may appear
only once. (Inserted below.)
- One "ElementEvents" at the document level is mandatory,
not optional (per XML spec).
- This shows only the clean "no error" case. I think
that to be complete, this needs to cover the "error"
case, which is always (yes?) required to include a
call to endDocument. I'd not even attempt to write
that as a grammar production -- just document that
any otherwise legal event sequence may short-circuit
straight to endDocument on any "abort parse" error.
- Re the Miscellanea (Miscellany?) in the HTML version,
I think it's right that errors not be in the main body.
HOWEVER I would flag resolveEntity calls, as I did below.
There are places they'll never appear.
And as a comment, it may not be realistic to expect that the prefix
mappings be perfectly nested ... as a group, yes, but not individually.
I don't think applications should care. That is,
startPrefixMapping ("foo", url1)
startPrefixMapping ("bar", url2)
startElement (...)
...
endElement (...)
// EITHER ORDER: foo then bar, or bar then foo
Also, I was under the understanding that startEntity/endEntity would
not appear within DTDEvents ... the beta2 spec is still weak on such
"PE within markup declaration" cases. (That's not just constructing
other markup decls using PEs, it's also conditional sections ... both
extremely common in nontrivial DTDs.) I think the operative phrase
was supposed to be that those "entity" would only apply to general
entities in content (not within start tags or empty element tags).
The issue you note at the end (re start/end entity) is supposed to
be resolved in beta2. However the PE version of the problem isn't
yet resolved. (And the PE example should use '%foo.flag;' ... ;-)
- Dave
> Mixing all possible events in from ContentHandler, DTDHandler,
> LexicalHandler, and DeclHandler, the legal event sequence appears to be:
>
> SAXDocument :=
setDocumentLocator? // OMITTED
> startDocument
resolveEntity? // OMITTED
> (processingInstruction | comment)*
> DTDEvents?
> (processingInstruction | comment)*
> ElementEvents?
// NOT OPTIONAL (no "?")
> (processingInstruction | comment)*
> endDocument
>
> DTDEvents :=
> startDTD DTDContent* endDTD
>
> DTDContent :=
> startEntity DTDContent* endEntity
> | elementDecl
> | attributeDecl
> | notationDecl
> | internalEntityDecl
> | externalEntityDecl
> | unparsedEntityDecl
> | skippedEntity
> | (processingInstruction | comment)*
// DON'T NEED NESTED/REPEATING
| processingInstruction
| comment
| resolveEntity // OMITTED
>
> ElementEvents :=
> startPrefixMapping*
> startElement
> ElementContent*
> endElement
> endPrefixMapping* # Note: "startPrefixMapping"
> # and "endprefixMapping" events
> # are balanced (by prefix name)
> # (and are nested?).
>
> ElementContent :=
> ElementEvents
> | startEntity ElementEvents* endEntity
> | characters
> | ignorableWhitespace
> | startCDATA characters* endCDATA
> | skippedEntity
> | (processingInstruction | comment)*
// DON'T NEED NESTED/REPEATING
| processingInstruction
| comment
| resolveEntity // OMITTED
>
>
> [terminals (which start with [a-z]) represent SAX2 events;
> non-terminals (starting with [A-Z]) added for structuring purposes.]
>
> For a more complete & possibly prettier document, see:
>
> http://www.mds.rmit.edu.au/~msf/misc/SAXEvents.html
>
> which includes the above, plus a brief description of each event
> and the SAX2 class to which the actual method belongs.
>
> Michael
>
> ***************************************************************************
> 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
> ***************************************************************************
***************************************************************************
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
***************************************************************************
|