- From: Eliot Christian <echristi@usgs.gov>
- Date: Wed, 08 Dec 1999 08:44:34 -0500
- To: www-xml-schema-comments@w3.org
- Cc: Frank Olken <olken@lbl.gov>, John McCarthy <JLMcCarthy@lbl.gov>, cmsmcq@uic.edu, xer-discuss@crxnet.com, asn1xml@oss.com
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