Re: Abbreviated Tag Names (ASN.1)

[Charles Reitzel <creitzel@mediaone.net>]

Some thoughts.

Surely, ASN.1 is preferable to inventing a new set of binary encodings for
XML Schema data types.

Besides being available now, ASN.1 has the advantage of interoperability
with LDAP.  I'm sure there are many uses for representing LDAP data as XML
and vice-versa: lookup web service deployment descriptors, directory data
export/import, UDDI registry implementation, ...

LDAP already defines "Syntaxes" for many primitive data types (date, string,
integer, ...).  LDAP has the ability to use different names for the same
OID, which might be helpful in supporting multiple XML views of shared LDAP
data.  Conceivably, these attribute types could be used independently of
directories, per se.

However, done with care and restraint, it shouldn't be to hard find a usable
overlap between LDAP schemas and XML Schema.  Both support basic "struct"
data types as well as attribute and element/entry type inheritance. 

Complications: 1) Because LDAP attributes are multi-valued, however, they
don't always map to XML attributes. So some additional meta-data is needed
here.  2) It is difficult to separate LDAP object classes from directories.
An XML data type is probably needed to represent an LDAP distinguished name
as a URI ("urn:ldap:cn=joebob,l=texas")?  However, LDAP relative
distinguished names (RDNs) can probably be represented with a properly
scoped XML Schema key definition.

Charles Reitzel


On Thu, 15 Feb 2001 Thomas B. Passin wrote:
>
>... you could consider asn.1 and perhaps an 
>xmlschema->asn.1->xml instance mapping.   All 
>the bit packing and so on has been worked out
>by the asn.1 folks - you have to come up with 
>the xml conversions.