Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX for Binary Encodings (SAD-SAX)
Amelia A Lewis wrote:
> There's no real point in implementing this as a pure sax
> filter, since that restricts you to type-less implementations.
> What you presumably want is (*cough*, *cough*) the
> Simple API for Datatypes.
Yes, and then we could have SAD-SAX ... :-)
Frankly, I'm a bit surprised by all the heat that has been
generated by what I thought was a very simple proposal. Clearly there
is something I'm not understanding... Please bear with me as I try to
be more explicit about what I'm suggesting. Then, *PLEASE* let me know
what it is that I'm not understanding...
Basically, all I think I'm suggesting is a small extension to
the ContentHandler interface of SAX2, the addition of two features and
a property. See below:
Extend ContentHandler:
public interface TypedContentHandler extends ContentHandler {
public void values(java.lang.Object value)
throws SAXException;
}
Add two feature flags to the XMLReader implementation:
http://wyman.com/sax/features/callbackCharacters (default =
TRUE)
http://wyman.com/sax/features/callbackValues (default = FALSE)
If callbackCharacters is True, then XML reader appears to be
100% SAX2 compliant. If false, then XMLReader should not callback to
characters. If callbackValues is True, then callback to it whenever
SAX2 would have normally calledback to characters. If both are true,
then callback to both but do characters first. If neither is true,
then don't do anything.
Add one property to the XMLReader implementation:
http://wyman.com/sax/properties/schema
Set this property to the URI for the schema file if one is to be
used.
I don't see that much more would needed to provide basic
"binary support" although I can think of all sorts of complicating
bells and whistles that would "sometimes" be useful... (i.e. bloat) Of
course, the default behaviour in all cases must be to behave exactly
as a SAX2 implementation would (i.e. callback to characters() and
return string data).
What is it about this proposal that generates the heat?
Obviously, I'm missing something here. Please try to explain the issue
as clearly as you can. Personally, I think it is pretty simple, clean
and obvious... To me it "looks like SAX"... And, as Amelia demands, it
is not defined "in terms of WXS" or any other type system. This is
good since SAX shouldn't be encumbered with the debate over these type
systems. Let those battles happen elsewhere.
Let me clarify that I do understand that getting support for
typed values in SAX is massively less important than just getting SAX
readers that can work with the binary types such as those in the ASN.1
defined binary encodings. The existing XML tools all assume SAX2 as it
stands today. What I'm proposing would simply allow a new class of
tool to be built in the future. But, at this point, leveraging what
we've got is clearly more important than enabling the building of new
stuff.
bob wyman
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
