[XML-SIG] SAX2: Parser properties

[uche.ogbuji@fourthought.com]

I'm sorry I'm responding so late, but better so than never, I hope.

> The first three properties come from the JavaSAX proposal, while the
> last one was invented by yours truly.
> 
> 
> http://xml.org/sax/properties/namespace-sep <String> (write-only)
>   Set the separator to be used between the URI part of a name and the
>   local part of a name when namespace processing is being performed
>   (see the http://xml.org/sax/features/namespaces feature).  By
>   default, the separator is a single space.  This property may not be
>   set while a parse is in progress (throws a SAXNotSupportedException).
> 
> http://xml.org/sax/properties/dom-node <Node> (read-only)
>   Get the DOM node currently being visited, if the SAX parser is
>   iterating over a DOM tree.  If the parser recognises and supports
>   this property but is not currently visiting a DOM node, it should
>   return null (this is a good way to check for availability before the
>   parse begins).
> 
>   This property doesn't make much sense for Python, but I see no point
>   in leaving it out, either.

Actually, we are planning a SAX writer for a (hopefully near) future version 
of 4DOM, and this could support this property.

> http://xml.org/sax/properties/xml-string <String> (read-only)
>   Get the literal string of characters associated with the current
>   event.  If the parser recognises and supports this property but is
>   not currently parsing text, it should return null (this is a good
>   way to check for availability before the parse begins).  I stole
>   this idea from Expat.
> 
> 
> In addition, I think PySAX needs the following property:
> 
> http://python.org/sax/properties/data-encoding <String> (read/write)
>   This property can be used to control which character encoding is
>   used for data events that come from the parser. In Java this is not
>   an issue since all strings are Unicode, but in Python it is. Expat
>   reports UTF-8, while xmlproc/xmllib just pass on whatever they're
>   given.
> 
>   Do we need a special SAXEncodingNotSupportedException for this?
>   Otherwise it may be impossible to tell whether the parser doesn't
>   support this at all or whether it just doesn't support this
>   particular encoding.

I agree that this is the best way to go for now, but I think the question 
should be at least raised as to whether it is better to agree on a normal 
encoding form for parser string output and enforcing this in the SAX drivers 
(by conversion, if necessary).

-- 
Uche Ogbuji
FourThought LLC, IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software engineering, project management, Intranets and Extranets
http://FourThought.com		http://OpenTechnology.org