[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX for Binary Encodings (SAD-SAX)

• To: "Simon St.Laurent" <simonstl@s...>
• Subject: Re: SAX for Binary Encodings (SAD-SAX)
• From: Alaric B Snell <alaric@a...>
• Date: Sun, 09 Nov 2003 01:00:44 +0000
• Cc: xml-dev@l...
• In-reply-to: <r02000200-1028-84D8A161122B11D88BED0003937A08C2@[192.168.124.11]>
• References: <r02000200-1028-84D8A161122B11D88BED0003937A08C2@[192.168.124.11]>
• User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030704 Debian/1.4-1

Simon St.Laurent wrote:

> I'd be thrilled to see ASN.1 readers which produce SAX2 events and ASN.1
> writers which consume SAX2 events.  I'm not happy to hear notions of
> PSVI-like typing polluting the SAX2 space.  If you want typing, find
> another API - and accept the costs of doing that.  If the ASN.1
> community wants to reach out to the XML community, it needs to create
> ASN.1 tools which talk to XML tools without imposing ASN.1's own and
> different perspective on how data should be presented.

I agree - don't jump to the conclusion that the ASN.1 community wants to 
impose anything; in my experience of moving amongst them, they don't 
want to impose anything on anybody apart from themselves, in pursuit of 
the greatest quality of available XML tools for the users! :-)

The only part of SAX which is really "string specified" is that fact 
that the leaf nodes and attribute values are represented by strings, 
right? I mean, there's probably some parser properties that only really 
have any meaning when dealing with strigs - perhaps one were you specify 
the character set - but that's a minor issue; a non-textual SAX source 
just ignores that option, I presume.

Now - to pass information to an application that involves typed values 
but is otherwise structured like XML, we have two options.

1) Have an optional SAX extension that emits typed values instead of 
character strings; of course, since we are neither stupid nor evil, 
we'll make it totally optional, so valid SAX implementations are under 
no burden to implement it if they don't want to, applications that don't 
use it are unchanged by its presence, etc.

2) We make an entirely new API which is pretty much identical to SAX 
exception that everything's renamed, and the leaf node / attribute value 
callbacks use Object (or your language's equivelant) instead of char[].

The argument for (1) is that it seems like a bit of a reinvention of the 
wheel, particularly since in many situations, an application would want 
to treat a part of an XML document as typed structured information while 
treating bits of it it's not interested in as characters to pass through 
verbatim and not worry about attempting to interpret them as anything, 
like my timeStamp example - meaning that the same application really 
wants to work with both models in parallel.

Now, as I see it, the argument for (2) is that a backwards-compatible 
optional extension to SAX might be a bit messy (having characters() and 
value() callbacks, along with something to allow attributes values to be 
provided as native data - even when some other attributes might not be 
typable by the parser...), rather than any fear of it polluting XML, 
since we clearly *can* do it in a non-polluting way...

ABS

• Follow-Ups:
  • Re: SAX for Binary Encodings (SAD-SAX)
    • From: Elliotte Rusty Harold <elharo@m...>

• References:
  • Re: SAX for Binary Encodings (SAD-SAX)
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: SAX for Binary Encodings (SAD-SAX)
• Next by Date: Re: SAX for Binary Encodings (SAD-SAX)
• Previous by thread: RE: SAX for Binary Encodings (SAD-SAX)
• Next by thread: Re: SAX for Binary Encodings (SAD-SAX)
• Index(es):
  • Date
  • Thread