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 ordering ofstartDocumen

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




 

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

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