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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Announcement: SAX2 1999-06-01 alpha release for Java

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: "XML Developers' List" <xml-dev@ic.ac.uk>
  • Date: Wed, 16 Jun 1999 09:46:45 -0400 (EDT)

David Brownell writes:

 > 	- I think the "validation" property should be immutable during
 > 	  parses; nonvalidating parses will generally discard data
 > 	  that a validating parse requires.

Agreed.

 > 	- Why shouldn't declaration and lexical handlers be set "at any
 > 	  time" during a parse, like the SAX1 handlers?

Is this the case with SAX1, or is it simply underspecified?

 > 	- When I implemented reporting of entity expansion for Sun last
 > 	  fall, I ran into a problem case that hasn't been addressed in
 > 	  the SAX2 draft.  Namely, entities in attributes ... consider
 > 	
 > 		<element attr="&entity;"/>
 > 
 > 	  will generally get reported as
 > 	
 > 		startEntity ("entity");
 > 		endEntity ("entity");
 > 		startElement ("element", {"attr", value-of-entity, ...} ...);
 > 		endElement ("element");
 > 
 > 	  which doesn't really make sense.  Sun's parser deals with this
 > 	  issue by not reporting such entity expansions.  It's not clear
 > 	  to me how SAX2 will deal with the issue.

I'm either to live with the status quo or to back out and scrap
reporting of entity boundaries altogether -- this is getting far too
complicated for far too little real reward.

 > 	- There's a similar issue with expanding parameter entities:
 > 
 > 		<!ATTLIST element
 > 			%common-attrs;
 > 			%i18n-attrs;
 > 			%optional-attrs;
 > 			attr NOTATION ( %notation-set-1; ) "fubar"
 > 			>
 > 
 > 	  And so on with conditional sections and other declarations; Sun's
 > 	  parser deals with that issue by not reporting parameter entity
 > 	  expansions through those reporting callbacks.

Ditto.

 >     Issues with what's NOT in the draft API, and where the lack is IMHO a
 >     notable API completeness issue for a "core" in SAX2:
 > 
 > 	- Information re NOTATION attributes is discarded.  In the example
 > 	  above, the attributeDecl() callback discards the list of which
 > 	  notations are permitted.  Suggested fix:  update the API.  Sun's
 > 	  API doesn't discard this info, others are also possible.

Agreed -- this needs to be fixed somehow.

 > 	- The internal DTD subset isn't available.  This means one can't
 > 	  reproduce the <!DOCTYPE...> declaration; some applications have
 > 	  convinnced me that they absolutely require that capability.
 > 	  Suggested fix:  as above, update the API (look at Sun's for one
 > 	  solution known to work).

The internal subset is available, indirectly -- it consists of
everything between the start/endDTD events outside of any
start/endEntity events.

 > 	- The SAX1 handlers aren't "gettable" in the way the SAX2 ones are.
 > 	  Suggested fix:  just define handler IDs for them.

That's a good idea.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

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

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