ASN.1 comments on XML Schema

Abstract Syntax Notation (ASN.1) is an international standard 
for the specification of data structures. It is used in a wide 
range of industries worldwide, including telephony, security 
(X.509/PKIX), transportation, air traffic control, power 
distribution, news services, parcel delivery tracking, 
"intelligent buildings", libraries and information services. 
On the Internet, ASN.1 is used for the specification of protocols 
such as SSL, LDAP, SNMP, Z39.50, voice, video, NetMeeting and 
various data such as genetic sequences.   

Over the last year, work has proceeded on the definition of 
XML encodings of data where the schema is defined using ASN.1. 
This work has been prompted by commercial considerations to 
allow XML-based tools to be used to support ASN.1-based 
specifications, and to provide two-way interworking between 
XML-based tools and ASN.1-based tools. This work would also 
allow data defined using XML Schema to be encoded using the 
Packed Encoding Rules of ASN.1, and thereby cater to 
applications that are band-width constrained.

Collaborative work in ITU-T and ISO/IEC will seek to standardize 
the additional specifications required for this interworking, 
such as: 

    ASN.1 XML Encoding Rules (XER) specifying how to carry 
    values of ASN.1 types as XML-encoded data, and 

    Mappings from XML schemas to ASN.1 type definitions and 
    from ASN.1 type definitions to XML schemas.
  
In reviewing the current Working Draft of XML Schema, it appears 
that an XML Schema would perform much the same structural and 
data-typing roles as an ASN.1 Specification. However, the 
following widely-used capabilities in ASN.1 seem to have no 
corresponding capability in XML Schema. For each of these, it 
would be useful to know if these capabilities can be added to 
XML Schema or what alternative work-around might be suggested. 

(1) Types can require multiple, disjunctive value constraints, 
   e.g., an integer constrained to have values only in the range 
   0-10 or 20-30. 

The requirement for multiple constraints could be as simple as 
allowing multiple occurrences for constraints that are expressed 
as sub-elements. (Constraints expressed as attributes may be 
problematic?)

(2) Types of variable length require validation of a minimum 
   length as well as a maximum length, e.g., a language code 
   constrained to be at least two characters in length.

This seems a straightforward addition symmetric with maxLength.

(3) Types can be constrained to multiple lengths, e.g. a Zip Code 
   constrained to have only a length of 5 or a length of 9.

A general mechanism to support multiple, disjunctive constraints 
may apply also to the length constraint. Absent such a general 
mechanism or a mechanism specific to the length constraint, a 
designer may have to use the regular expression facility (it is 
not clear how regex would be used with all data types).

(4) Constraints are often defined by a negation, e.g., a 
   sub-element constrained to be absent.

Although negation can be avoided logically by requiring designers 
to express all constraints in the positive, this would not be 
seen as very friendly. A logical "not" is quite commonly used 
for expressing constraints on values.  
   
(5) Bits can have names, e.g., in X.509 a Key Usage bit string 
   has named bits where the name indicates usage such as the first 
   bit for DigitalSignature, the second bit for Authentication, etc. 

Given <element name="KeyUsage" type="binary">, perhaps a syntax 
could be provided for sub-elements such as:
         <bit name="DigitalSignature"/>
         <bit name="Authentication"/>

(6) Values can have names, e.g., a Digital Certificate
   version is indicated by the value in a message element and 
   the version is referenced elsewhere in the ASN.1 Specification.

Perhaps this requirement could be handled at a general level by 
allowing the declaration of constants. So, if the string value "DC" 
indicates Digital Certificate, might there be a syntax such as:
   <constant name="Digital Certificate" type="string">DC</constant>  

We look forward to your reply and thank you for your attention to 
these issues.

  
  


    


Eliot Christian, US Geological Survey, 802 National Center, Reston VA 20192
echristi@usgs.gov  Office 703-648-7245  FAX 703-648-7112  Home 703-476-6134

Received on Wednesday, 8 December 1999 08:43:50 UTC