- From: Stephen D. Williams <sdw@lig.net>
- Date: Mon, 29 Nov 2004 19:12:40 -0500
- To: Paul Thorpe <thorpe@oss.com>
- Cc: bob@wyman.us, 'David Ryan' <david@einet.com.au>, public-xml-binary@w3.org
The standards I mentioned below were those I found referenced in the ASN.1 related standards. I didn't state or believe that anything was necessary, only that those standards are referenced by the ASN.1 standards. Relevent sections state that the details of encoding are given in those other standards which leads me to believe that there are needed details that are not in the ASN.1 standards. If the ASN.1 standards are self-contained as a set, then they shouldn't say something like "and encoded according to ISO 6093" (X.690-0207 8.5.7). I don't actually expect that every such instance would be imported, but it is a problem if the standards needed are costly. IEEE float/double format standards documentation is also likely to be an expensive document, but it is widely documented: http://stevehollasch.com/cgindex/coding/ieeefloat.html I didn't mean to suggest that ASN.1 can't transport binary data. The point was that ASN.1 does directly support certain data types in certain encodings but that one stated current need is to transport native real formats. Those who want this don't want to rely only on private convention for reals, they want integral support from standards and libraries, just like ASN.1 software provides for its 'native' encodings. If it is appropriate to encode scalars in binary, as ASN.1 does, it could be argued that for efficiency reasons that native formats should be supported. If the argument is that native formats are too hard to support in all architectures and implementations or something and efficiency isn't important, then why not just use XML 1.x text encoding? I would far rather use a text encoding than a binary encoding. I'm only interested in a binary XML solution to get much more efficiency in all of its forms, including support for new semantics that allow many types of application efficiency. To reiterate, the structural efficiency is a separate problem from the data typing and representation efficiency although both are implemented in the same libraries. Fast Infoset is indeed a good direction. I believe it is missing support for certain properties that I find very useful, but it is a better solution than past patterns. sdw Paul Thorpe wrote: >On Mon, 29 Nov 2004, Stephen D. Williams wrote: > > > >>That's great, what about: >> >>ISO 8601 (calendar date reference) 108 CHF >>http://www.cl.cam.ac.uk/~mgk25/iso-time.html >>http://www.cs.tut.fi/~jkorpela/iso8601.html >>http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html >> >> > >There are two time types (GeneralizedTime and UTCTime) in ASN.1 (based on >ISO 8601) in which the encodings are fully described in the ASN.1 >standards with no need to buy ISO 8601. > >Work also currently in progress on supporting a more generic TIME type >which will support all formats specified in ISO 8601. > > > >>ISO 6903 (Real Decimal Spec) 67 CHF >> >>ISO 2022 character encoding 142 CHF >>http://en.wikipedia.org/wiki/ISO_2022 >> >> > >Why do you believe this is necessary? The ASN.1 group has long been >suggesting that new specs avoid use of the obsolete "GeneralString" and >related string types, and use IA5String (for ASCII) or UTF8String for >international alphabets. > > > >>ISO 10646 (UCS, directly related to Unicode) 110 CHF >>http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html >> >> > >ISO/IEC 10646 is aligned with Unicode published by the Unicode Consortium. >You can just as easily get that free. > > > >>I'm sure I missed a number of other references that are needed. >>Pointers to free versions of those would be helpful. What about a map >>of dependent standards? >> >>I tend to think that the encoding aspects of ASN.1 work should be >>useful, but then I closely examine the encoding for reals and find that >>it is not aligned with the current thinking of many that they want to >>directly transport IEEE and other native formats in a reader-makes-right >>fashion. >> >> > >Why do you think that ASN.1 cannot transfer arbitrary binary data? > > > >>A different and more fundamental issue is that strong schema orientation >>is no longer considered the only or necessarily the best way to work. A >>number of useful and highly desirable properties, including being able >>to avoid schemas, have been derived from actual use cases. These >>requirements include many things that don't seem possible with ASN.1 >>related standards and technology, or with most other approaches. It >>makes sense to consider what solutions might answer a more broad set of >>requirements and principles while learning everything possible from >>existing methods. >> >> > >You seem to be looking for the X.891 (Fast Infoset) standard which is >currently under ballot in ISO. This will allow arbitrary >namespace-well-formed XML documents to be represented in compact binary >form without an associated schema. > >Paul > > > >>sdw >> >>Paul Thorpe wrote: >> >> >> >>>On Mon, 29 Nov 2004, Stephen D. Williams wrote: >>> >>> >>> >>> >>> >>>>After 20+ years, ASN.1 related software and standards haven't evolved >>>>and become available in ways that satisfy many current requirements or >>>>developers. There are many reasons for this. >>>> >>>>Could you point me to free, public specifications of those encoding >>>>format details and the ASN.1 schema definition semantics? >>>> >>>>sdw >>>> >>>> >>>> >>>> >>>The complete set of ASN.1 standards documents are available free from the >>>ITU-T SG17 website. The URL is: >>> >>>http://www.itu.int/ITU-T/studygroups/com17/languages/index.html >>> >>>The X.680 and X.690 series of documents make up the complete ASN.1 >>>standard. This includes X.693 (XML encoding rules) and X.694 (Mapping W3C >>>XML schema definitions into ASN.1). >>> >>>---------------------------------------------------------------------------- >>>Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 >>>OSS Nokalva International: 1-732-302-0750 >>>Email: thorpe@oss.com Tech Support : 1-732-302-9669 >>>http://www.oss.com Fax : 1-732-302-0023 >>> >>> >>> >>> >>>>Bob Wyman wrote: >>>> >>>> >>>> >>>> >>>> >>>>>David Ryan wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I'd be interested if anyone is working on, or knows of >>>>>>binary formats with similar characteristics of binary XML >>>>>>but is not based on XML? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> The encoding formats that have been defined for ASN.1 are the >>>>>"classic" binary formats that you would want to study. ASN.1, the "abstract >>>>>syntax notation 1", has been around for something like 20 years now and can >>>>>be used to define a wide variety of formats including text based formats >>>>>like XML as well as the binary formats BER, PER, DER, etc. ASN.1 is most >>>>>commonly known as the schema language for SNMP, X.500 Security Certificates, >>>>>etc. Also, ASN.1 is relied on heavily by the telecommunications industry. >>>>> In my opinion, the most logical thing for the W3C to do is accept >>>>>ASN.1 as an XML Schema language (it's use as one is defined by international >>>>>ISO standards) and to rely on the 20 years of development by the ASN.1 >>>>>community in developing and supporting binary formats. We don't need >>>>>yet-another-standard format and it is unlikely that any new effort is going >>>>>to be able to satisfy any larger community then the ASN.1 effort has been >>>>>able to address in 20 years of listening to and responding to requirements. >>>>> >>>>> bob wyman >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st >>>>Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>-- >>swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st >>Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw >> >> >> >> -- swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
Received on Tuesday, 30 November 2004 00:11:00 UTC