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

RE: SAX for Binary Encodings (preserving investment) (ASN.1 an

• To: <xml-dev@l...>
• Subject: RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• From: "Alessandro Triglia" <sandro@m...>
• Date: Mon, 10 Nov 2003 11:54:31 -0500
• Importance: Normal
• In-reply-to: <001501c3a7a2$0e278f40$b894c044@aldebaran>

I wrote:
> 
> 
> Bob Wyman wrote:
> > 
> > I argue that if something is
> > marked to be an attribute when converted to XML, then it 
> > should be marked as an attribute when it is passed through an 
> > interface like SAX which is commonly used to process XML-like 
> > data. If this were not the case, then binary data would look 
> > different to the user of SAX when it was read directly via 
> > SAX rather than being read from a chunk of XML written by the 
> > XML encoder. This would be silly and unproductive.
> 
> 
> I absolutely agree.  Another way of saying this is that the 
> stream of SAX
> callbacks coming from parsing/decoding an encoding of ASN.1 (BER, PER,
> EXTENDED-XER) has to be exactly the same stream, for a given 
> schema and a
> given instance, regardless of the encoding rules in use (BER, PER,
> EXTENDED-XER), and has to be the same stream as would be 
> generated by a
> "normal" SAX parser parsing the XML document.  It must be possible to
> replace a normal SAX parser used by an application with an ASN.1
> parser/decoder for either XML or binary encodings with 
> minimum changes to
> the application code.  This will give us the interoperability we need
> between the two worlds.


And it is not just about attributes vs. elements.  It is also about: 

- mixed content,

- variable-order sequences (those consisting in a group of elements whose
order in the instance "doesn't matter" (*)), 

- removing wrappers around multiple occurrences of things,

- CHOICEs corresponding to XSD's type derivation hierarchies,

- CHOICEs corresponding to XSD's element substitution groups,

- CHOICEs corresponding to XSD's unions,

- "SEQUENCE OF"s corresponding to XSD's lists,

- support of wildcards,

and so on.

All these features (and others) are supported by an XER-specific notation in
the ASN.1 schema, which affects EXTENDED-XER encodings but does not affect
BER/PER encodings.  However, a SAX XMLReader over BER/PER should behave *as
if* BER/PER encodings contained some representation of the above things as
EXTENDED-XER does.

Alessandro Triglia


(*) or "matters", depending on people's views and use cases (ASN.1 supports
both views/use cases).


> 
> Alessandro Triglia
> 
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 

• References:
  • RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
    • From: "Alessandro Triglia" <sandro@m...>

• Prev by Date: RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• Next by Date: RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• Previous by thread: RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• Next by thread: RE: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• Index(es):
  • Date
  • Thread