# Presentation: 922443

**XML Encoding Rules (XER)**

**Rob Bull  bull@crxnet.com**

## Original Requirements...

- An immediate need (Nov. 1998):
- An abstract specification of search was needed to respond to the OpenGIS Consortium RFP for Catalog Services  - CORBA, COM, Z39.50, SQL, and LDAP)
- XML (eXtensible Markup Language) chosen as the notational syntax for the Catalog Services search specification

## Basic Concept of XER

- Rules to convert between XML and BER (Basic Encoding Rules) for a protocol specified in ASN.1 (Abstract Syntax Notation)
- Standardized rules for transforming:
- BER encoded structures into equivalent XML structures
- XML encoded structures into equivalent BER structures

## Scope...

- ASN.1 is used in a variety of applications, protocols, and network environments with various encoding rules (e.g., BER, PER, DER)
- XML provides a facility for representing character string structures and their markup rules
- initial XER focus is Z39.50-1995 (ISO 23950)  Search and Retrieval protocol
- In the Z39.50 community:
- ASN.1 is used with BER
- potentially applicable to LDAP (lightgweight directory access protocol) and SNMP (simple network management protocol)

## For example...

- 	PDU ::= CHOICE{	searchRequest   [22]   IMPLICIT  SearchRequest,	searchResponse [23]   IMPLICIT  SearchResponse,
- 	SearchRequest ::= SEQUENCE{	resultSetName    [17]   IMPLICIT InternationalString,	databaseNames  [18]   IMPLICIT SEQUENCE OF DatabaseName,        query                [21]   Query
-     SearchResponse ::= SEQUENCE{        resultCount                         [23] IMPLICIT INTEGER,        numberOfRecordsReturned   [24] IMPLICIT INTEGER,        nextResultSetPosition           [25] IMPLICIT INTEGER,        searchStatus                       [22] IMPLICIT BOOLEAN,        resultSetStatus                    [26] IMPLICIT INTEGER,        records                                      Records   OPTIONAL,

## XML Encoding: SearchRequest

- <?xml version='1.0'  ?><search xmlns="urn:oid:1.2.840.10003.2.1">    <searchRequest>         <resultSetName> **1**  </resultSetName>         <databaseNames> **xxdefault **</databaseNames>         <query> **[ query on next slide ] **</query>  </searchRequest></search>

## XML Encoding: Query Detail

- 	<query>   <type-1>      <rpnQuery>         <attributeSet> **BIB1** </attributeSet>         <rpn>            <rpn> **[operand next slide] **</rpn>            <rpn> **[operand next slide]** </rpn>            <operator> **AND** </operator>         </rpn>      </rpnQuery>   </type-1></query>

## XML Encoding: Operand Detail

- 	<operand>  <attributeValue> **CreationDate**  </attributeValue>  <attributeValue> **Greater Than or Equal**  </attributeValue>  <attributeValue> **Date** </attributeValue>  <term> **1995-01-01** </term></operand>

## XML Encoding: SearchResponse

- 	<?xml version='1.0'   ?><search xmlns="urn:oid:1.2.840.10003.2.1">  <searchResponse>     <resultCount> **76** </resultCount>     <numberOfRecordsReturned>**0** 			</numberOfRecordsReturned>    <nextResultSetPosition> **0** 			</nextResultSetPosition>    <searchStatus> **<true/>**</searchStatus>  </searchResponse></search>

## Development Approach...

- e-mail list to discuss XER design and issues
- Participants/listeners include:
- commercial (large, small)
- desktop software suppliers, telecoms suppliers
- database software suppliers
- Z39.50 and ASN.1 toolkit suppliers and consultants
- academic
- research
- Xer syntax and rules have been discussed and a draft set of rules created

## Development Approach...

- Software developed
- Profile for Z39.50 over HTTP discussion paper
- Presentation to ASN.1 committee at Geneva in June 1999
- has already spawned interest such as ONE-2 project

## Decisions and Proposals...

- Three categories of decisions and proposals:
- decisions where consensus is reached
- proposals that generally affect XER
- proposals that specifically affect XER and Z39.50

## Consensus Reached...

- The XER generated XML should be readily understandable
- XER is generally applicable to ASN.1
- XER requires well-formed XML
- No distinction between explicit, implicit
- encode and decode assumes XER is implicit
- applications need to know ASN.1 and can make BER implicit or explicit
- ASN.1 1994 has concept of automatic tags

## Consensus Reached...

- named values as empty elements, so its not:
- <protocolVersion>version-1, version-2</protocolVersion>
- but it is:
- <protocolVersion><version-1/><version-2/></protocolVersion>
- uses XML namespace attribute to identify particular XML
- non-validating
- some aspects of the XML record structure can be inferred from well-formed values
- beyond the inferred structure various methods exist, there is always the base ASN.1 specification for validation

## Proposals...

- XML namespace decisions
- adding private PDUs
- how to represent tags for OIDs
- Testbed
- z39.50 client   (BER)
- BER/XER gateway  (XER)
- XER/BER gateway  (XER)
- Z39.50 server (BER)

## Draft XML Encoding Rules

- 	7.1 General rules for encoding7.2 Encoding of a boolean data value7.3 Encoding of an integer data value7.4 Encoding of an enumerated data value7.5 Encoding of a real data value7.6 Encoding of a bitstring data value7.7 Encoding of an octetstring data value7.8 Encoding of a null data value7.9 Encoding of a sequence data value7.10 Encoding of a sequence-of data value7.11 Encoding of a set data value7.12 Encoding of a set-of data value

## Draft XML Encoding Rules

- 7.13 Encoding of a choice data value
- 7.14 Encoding of a ASN.1 tagged data value
- 7.15 Encoding of an open type
- 7.16 Encoding of an instance-of data value
- 7.17 Encoding of a data value of the embedded-pdv type
- 7.18 Encoding of an object identifier data value
- 7.19 Encoding of a data value of the external type
- 7.20 Encoding for data values of the restricted character string types
- 7.21 Encoding for data values of the unrestricted character string type
- 7.22 Encoding for data values of the any character string type
- 7.23 Encoding for data values of the general string type
- 7.24 Encoding for data values of the visible character string type

## Profile for Z39.50 over HTTP

- Discussion paper, second draft, April 1999
- Architectural Issues:
- Z39.50 is described in ASN.1 but encoding is via XER
- requirement for stateful/stateless applications
- stateless - single HTTP request/response sequence comprises an entire Z-association
- stateful - a Z-association is maintained across multiple TCP/IP sessions
- Z39.50 PDUs will be encapsulated within HTTP protocol messages using the “Search” method

## Profile for Z39.50 over HTTP

- proposed approaches to mapping HTTP requests and responses to Z39.50 requests and responses
- considerations for:
- stateful, stateless
- Z39.50 state-machine
- how do we handle “trickier” services such as access control, resource control, segmentation, trigger resource control

## Software Developed so far...

- European Commission, Joint Research Centre, Ispra, Italy:
- On http://perlz.jrc.it/ a library for handling XER encoded packets with Perl is available
- The Z39.50 library contains, as an example, a gateway from XER to BER and back
- BER to XML conversion library (Warnock/ Gamiel)
- 	demonstration utility, software description

## Opportunities....

- XML developers
- leverage investments in ASN.1-based applications already interoperable
- ASN.1 developers
- leverage investments in XML-based applications coming up on the Internet

## Further information...

- XER home page      http://asf.gils.net/xer
-  with pointers to:
- documentation on XER concept
- details on rules defined
- software
- example PDUs
- decisions and proposals
- XER discussion list and the list archive
- Profile for Z39.50 over HTTP:
- http://lcweb.loc.gov/z3950/agency/zhttp.html

## Credits...

*This presentation incorporates content from a presentation to the*ASN.1 Committee Geneva, June 9, 1999 byEliot Christian, U.S. Geological Survey and
- Nick Hibma, E.C. Joint Research Commission