ASN.1 ITS
In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities. ASN.1 is a joint ISO and ITU-T standard. (source: Wikipedia)
The 'A' in ASN.1 is for "Abstract". ASN.1 defines an abstract data model that can be encoded in a number of ways. Two of the most common binary encodings are PER (packed encoding rules -- these are what Sun uses in the Fast WebServices) and BER (basic encoding rules). There is also a specification for XML encoding rules (XER), as well other encoding specs.
There may well be debate on design issues for ASN.1 , but in my experience this is much less contentious than with XML. You don't have issues such as "elements vs. attributes" or "DTD vs. Schema vs. Schematron vs.Relax NG vs. ...". And most importantly, by separating the conceptual data model from the possible encodings, ASN.1 lends itself to thinking more about data modeling and less about "how it will look". "How it will look" is left to the particular encoding rules one chooses to use.
ASN.1 is used extensively by the telecommunications industry. My understanding is that if you use a cell phone, you are probably already using ASN.1 without knowing it. It is also used in a number of other areas (e.g . all message structures in Kerberos 5 -- a very common authentication service -- are defined in ASN.1).
There are both open-source and commercial tools available for working with ASN.1.
ASN.1 ITS
The ASN.1 ITS should be developed it from the abstract spec using ASN.1 paradigms.
Note: There is at least one commonly accepted algorithm for converting between XML and ASN.1 (bidirectionally). However, ASN.1 and XML are different languages with a common purpose (data representation). Each has its strengths and weaknesses. Using a canned algorithm for creating ASN.1 from the XML ITS would be similar to using a canned algorithm for creating Java from the XML ITS. It can definitely be done, but it ignores many of the efficiencies or elegant features of the second language.
By defining an ASN.1 ITS, we automatically have the ability to represent the content in any of the ASN.1 encodings. This has the potential to become confusing -- HL7 would in effect have two standard XML representations -- but is also very powerful. For example a message in the ASN.1 ITS could be transmitted across the wire using PER for efficiency, and then be efficiently transliterated to XER for XSLT processing, all using existing tools.
Discussion
(Craig Parker) I think the biggest risk of creating an ASN.1 ITS would be fighting the urge to purify the the V3 abstract spec from the XML paradigms that crept into it.
- If we only had this for a reason to create the ASN.1 ITS it would be sufficient reason.. One of the reasons why we need to have more than 1 ITS is the simple fact that the abstract specs need to work long after XML is dead and gone and been replaced by something else. XML paradigms do not belong in the abstract spec and should be removed. Rene spronk 03:32, 18 Mar 2006 (CST)
- (Paul Biron) The AD and EN data types are abstractly "mixed content"
(Stan Huff) If there is a need, I think an asn.1 ITS would be feasible and would have some advantages over XML. One of the main advantages would just be size of the data transmitted. BER asn.1 is roughly one tenth the size of XML encoded data.
(Stan Huff) As one point I made an asn.1 definition of the HL7 V3 data types. I could probably find that if people are interested. I haven't kept it up to date, but it might be of interest to people just to get a feel for what asn.1 definitions look like.
See draft ASN.1 data types spec from 2001.
(Dave Loyall) +1. Is has new work happened on this since the last post here?
References
Another good resource for ASN.1 information is: France Telecom
