Eliot Christian
E-mail: echristi@usgs.gov
US Geological Survey, 802 National Center, Reston VA 20192
Office 703-648-7245 FAX 703-648-7112 Home 703-476-6134
Alan Kent
Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
E-mail: ajk@mds.rmit.edu.au Web-site:http://www.mds.rmit.edu.au
Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098
George Percivall
E-mail: george@sgt-inc.com
Doug Nebert (via Eliot Christian)
E-mail: ddnebert@usgs.gov
Eliot Christian posted the following message 98/11/07:
Some folks are looking into the feasibility of creating a utility for using an XML encoding for Z39.50 PDU's--what one might call XER (XML Encoding Rules). The basic idea is to standardize rules for transforming appropriate ASN.1 encoded data structures into equivalent XML data structures and appropriate XML encoded data structures into equivalent ASN.1 data structures.
I've made a place to post stuff related to this idea at
http://asf.gils.net/xer
Alan Kent responded 98/11/16:
We have a utility to encode/decode ASN.1 as SGML (probably XML conformant too). We used a different approach however. We modified the SNACC compiler so it generated/read XML. Rather than pick an element name per field (which is an approach we considered), we used a very generic DTD and put ASN.1 field names into elements. We also used very short tag names to keep the output as short as possible.
Is this a better approach? Probably not. But it meant we can validate the SGML/XML against a DTD that will work for any ASN.1 definition. Its not limited to Z39.50. The DTD is below in case anyone is interested.
Looking at the XER DTD and samples, I noticed the sample XML did not conform to the DTD in places.
Eliot: Yes, the DTD was created by hand by Margaret St Pierre. I created the XML sample by hand modifying output of a tool created by Bancroft Scott of Open Systems Solutions. The DTD was used in an proposal to the OpenGIS Consortium on Catalog Services. The XML generation was a proof of concept to uncover any potential show-stoppers on the path to automated XML Encoding Rules in a way that is loss-less and reversible.
George P added the following, 98/11/17:
The EO/GEO Team proposal to the OpenGIS Consortium is available via anonymous ftp at
MS Word 98 format: harp.gsfc.nasa.gov/incoming/OGC_Catalog/EO_GEO_OGC.doc
MS Word 6 format: harp.gsfc.nasa.gov/incoming/OGC_Catalog/EO_GEO_OGC.wd6
This is the initial submission of the OGC spec.
Alan: Also it uses symbolic names for record syntaxes and attribute set names (USMarc, Bib-1 etc) so these would all have to be formally defined too.
Eliot: We are also looking at extending the OID tree down into Attribute Sets so as to provide names for Types (Use, Relation, Position, Structure, Truncation, and Completeness) and Attributes (Personal-Name, Corporate-Name, Conference-name, Title, etc.). A space delimited text file of possible names down through Bib-1 and GILS is at http://asf.gils.net/xer/asn1/XML-tags.txt. I am interested in any thoughts about managing this stuff as a distributed database of Z39.50 OID/Type/Attributes using LDAP facilities for update and query.
Alan: The DTD also did not include all of Z39.50, so I am guessing the DTD is to illustrate the point, not to be complete.
Eliot: Yes
Alan: I also noticed that the DTD cannot be automatically generated from the ASN.1 specification, which I think is a more serious problem as I think automation is important for practical use (personal opinion). I think it would be a mistake to have to maintain effectively two copies of the Z39.50 standard - the ASN.1 and the XER where the mapping between the two must be defined (although its pretty obvious for humans reading the XER encoding).
Eliot: I agree totally and that is certainly the goal for XER.
Alan: Anyway, interesting stuff. If the XER encoding can be derived from the ASN.1 spec, I might be able to put up a ASN.1<->XER encoding tool if people are interested. If the XER encoding requires human intervention, its a lot harder!
Eliot: I think there is certainly interest!
Alan: ps: The DTD we have used internally is as follows:
<!-- ASN.1 representation in SGML.
The element names have been kept short to reduce the length of SGML encodings of ASN.1 packets. The SGML is only going to be manipulated by programs. Attributes have not been used to make it possible to write a very simple parser. No end tag omitable etc. has been allowed for the same reason. -->
So a packet would be something like:
This is clearly not as human readable as the XML approach being proposed. But it does allow any extensions to be supported without changing the DTD (probably not a big issue).
On 98/11/17, Eliot also posted a copy of Doug Nebert's message re: BER to XML conversion library available:
The BER-to-XML converter library is located at
Note from ILLASMA: Converter library no longer available.
It contains the OCLC BER utilities and a single callable routine which converts a PDU into the associated XML representation. It is closely aligned with the DTD Margaret St. Pierre has developed, although some iterations may be necessary to decide on both a final DTD and a final version of the software.
The conversion routine is completely table-driven which should permit easy modification and customization. Archie Warnock is working right now to put together a little demonstration client which will incorporate it into a sample Z39.50 client. We'll post more news when it's available.