Lists Home |
Date Index |
Robin Berjon wrote:
> An XML parser can successfully read anything produced based
> on an XML schema language (not to mention all that can be
> done without any schema) -- unless that schema language is
> ASN.1 (which could be an argument for saying it isn't exactly
> an XML schema language).
Just because ASN.1 works with encodings other than XML doesn't
mean it is any less useful in describing XML. The fact that it works
with other encodings doesn't make it less of an "XML Schema Language."
Also, it can be argued that ASN.1 works *better* with XML than some
things popularly considered to be "XML Schema Languages" since ASN.1
supports a wider range of XML encoding possiblities than some (but not
all) of the others do.
The issue you mention, is with the encodings -- not the
abstract syntax. Certainly, an XML parser can't "read anything
produced based on" some encoding other than XML. It doesn't matter if
that non-XML encoding was produced by something from the ASN.1 suite
or something entirely different (e.g. XDR).
> If all you have is an ASN.1 schema, and you're on the
> receiving side, you don't know what you're going to get.
> If it's an ER you don't know about you won't read it.
Right. Once you have choice, you need to have a way of
discovering what choices were made. You need a way to tag an encoding
with its type. This is not a problem unique to the encodings defined
by ASN.1. The same problem will arise with *any* alternative encoding
of XML data -- including all the various proposals for a "binary XML."
This will even be true if "binary XML" is simply zipped text.
These days, we tend to use MIME types for this sort of thing.
That's why I've begun a discussion on the asn1xml mailing list to work
up a proposal for registering MIME types for the various encodings
defined in ASN.1 land.