OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   No Subject

[ Lists Home | Date Index | Thread Index ]
  • From: Charles Reitzel <creitzel@mediaone.net>
  • To: xml-dev@ic.ac.uk
  • Date: Wed, 14 Apr 1999 12:20:06 -0400 (EDT)

I saw this comment and felt compelled to share my thoughts.  While I agree
data type inheritance is a useful thing, it seems outside the scope of XML.
But there are alternatives.

David Megginson wrote:
>Universal names (as in "Namespaces in XML") get you part way there,
>because different document types can share semantics of well-known
>element types: 

... namespace example <html:title> snipped ...

>What's really useful, though, is to develop some kind of inheritance
>scheme, so that you can say "this is just like an html:title, except
>that it's also a little more specialised".  Architectural forms
>provide a very lightweight mechanism for this; XML Schemas will
>probably provide another.

I would suggest to folks who need this level of data type reuse and/or
sophistication that they look into ASN.1.  This is the ISO data type
definition language used to define the SSL, SNMP, X.500 and LDAP protocols.
The language itself is very general and has many benefits.  It supports all
the basic data types and compound data types (i.e. C++ structs).  It
supports inheritance for the same. There is a global object namespace
(Object ID, or OID for short), wherein each firm or organization can
register a base ID namespace in which all "custom" object types can be
defined.  Thus, they (the ISO) have solved both the FPI and namespace
problems that has caused XML-Dev'ers so much grief.  Perhaps most important,
all datatypes defined using ASN.1 have a standard, unambiguous method of
encoding the data for transmission on the wire.  These rules are known as
the "Basic Encoding Rules", or BER, of ASN.1.

Certainly, a general ASN.1 parser is non-trivial.  The subset required for
any given protocol (e.g. LDAP) is easy enough, however.  Basically, ASN.1
statements can be understood as a simple, elegant DTD language.  The
"document" equivalent is not text, but the binary image defined by applying
the BER to ASN.1 datatypes.  In this context, ASN.1 itself doesn't need a
mime type.  But the protocols developed with ASN.1 do.

So, I would use well-formed XML for basic, web based data transfer.
Schemas/DTD/SGML for complex document work.  LDAP/X.500 for inter-operable
data exchange.  SNMP for inter-operable device/application management.
ASN.1 based private protocol for custom application work.

Best regards,
Charles Reitzel


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


  • Follow-Ups:
    • Re: ASN.1
      • From: David Brownell <david-b@pacbell.net>



 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS