Requesting XML records via Z39.50

[ray denenberg]

I would like to revisit the implementor agreement on "Requesting XML
Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html, as it has
been many years since it we've discussed it, and it does seem to warrant
some clarification.

Briefly,  to retrieve records according to a specific XML schema using
Z39.50 (if you DON'T want to use compSpec):
1. XML is specified as the record syntax,  specifically 'xml-b':
1.2.840.10003.5.112.
2. The schema identifier is specified as the element set name.

This has come up in discussion with a few implementers, some who want to
retrieve holdings records (ISO 20775), others marcXchange records (ISO
25577), as well as subschemas of these two schemas.

As a result of that discussion I have registered the following:

1.2.840.10003.13.11   ISO 20775 Schema for holdings
http://www.loc.gov/standards/iso20775/

1.2.840.10003.13.11.1  the holdingsHistory subschema (element set) of ISO
20775 Holdings Schema

1.2.840.10003.13.12 'MarcXchange'  ISO 25577 XML schema for MARC formatted
records
http://www.loc.gov/standards/iso25577/

1.2.840.10003.13.12.1  danMARC2 subschema of MarcXchange

1.2.840.10003.13.12.2  MarcXML subschema of MarcXchange
http://www.loc.gov/standards/marcxml/


Please comment, particularly implementors who retrieve XML records but don't
do it this way.

 If there is no discsussion on this (say, by February 9), I will re-write
the implementor agreement with appropriate clarification.

--Ray

[Archie Warnock]

Ray Denenberg, Library of Congress wrote:
> I would like to revisit the implementor agreement on "Requesting XML
> Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html, as it
> has been many years since it we've discussed it, and it does seem to
> warrant some clarification.

And note that the link in that page
(http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer valid.

> Briefly,  to retrieve records according to a specific XML schema using
> Z39.50 (if you DON'T want to use compSpec):
> 1. XML is specified as the record syntax,  specifically 'xml-b':
> 1.2.840.10003.5.112.
> 2. The schema identifier is specified as the element set name.

Somehow I missed the original Implementor's Agreement and Isite has been
happily chugging along without it.  We don't use compSpec in Isite but
the majority of uses are homogeneous enough that we haven't had to (nor
been asked to) rely on the agreement.  The old XML OID (we've been using
1.2.840.10003.5.109.10) is sufficient for us - I just return the only
XML we know about - ie, the record we ingested.  This works reasonably
well since the schema is usually either known or agreed to a priori or
included in the XML anyway, in which case the returned XML is
self-documenting and it's up to the requesting client what to do with it.

I have no objection to implementing the convention, provided there's no
implied agreement to _transform_ records into the requested schema.  My
inclination would be to return either the record, if we know and can
provide the particular schema or to return an error if we don't (ie, it
would be treated like an unsupported element set).

--

Archie

-- Archie Warnock                         warnock@...
-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I _do_ speak for my employer.

[ray denenberg]

Archie, I don't want anyone to change their implementation behavior based on
the existing or a revised agreement.  So this is useful feedback, thanks.
I would like to incorporate existing implementation practice into the
revised procedure.

I think that the 110 record syntax was first registered with the idea that
the XML schema was known by private agreement.  (Subseqently we registered
112 to use in the case when you want to also specify the schema.)  It sounds
like what you are doing is consisitent with what we had in mind.  I'll write
this into the revised agreement.

Any other feedback on this is also welcome.

--Ray

----- Original Message -----
From: "Archie Warnock" <warnock@...>
To: "Ray Denenberg, Library of Congress" <rden@...>
Cc: <www-zig@...>
Sent: Monday, January 26, 2009 2:24 PM
Subject: Re: Requesting XML records via Z39.50

> Ray Denenberg, Library of Congress wrote:
>> I would like to revisit the implementor agreement on "Requesting XML
>> Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html, as it
>> has been many years since it we've discussed it, and it does seem to
>> warrant some clarification.
>
> And note that the link in that page
> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
> valid.
>
>> Briefly,  to retrieve records according to a specific XML schema using
>> Z39.50 (if you DON'T want to use compSpec):
>> 1. XML is specified as the record syntax,  specifically 'xml-b':
>> 1.2.840.10003.5.112.
>> 2. The schema identifier is specified as the element set name.
>
> Somehow I missed the original Implementor's Agreement and Isite has been
> happily chugging along without it.  We don't use compSpec in Isite but
> the majority of uses are homogeneous enough that we haven't had to (nor
> been asked to) rely on the agreement.  The old XML OID (we've been using
> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
> XML we know about - ie, the record we ingested.  This works reasonably
> well since the schema is usually either known or agreed to a priori or
> included in the XML anyway, in which case the returned XML is
> self-documenting and it's up to the requesting client what to do with it.
>
> I have no objection to implementing the convention, provided there's no
> implied agreement to _transform_ records into the requested schema.  My
> inclination would be to return either the record, if we know and can
> provide the particular schema or to return an error if we don't (ie, it
> would be treated like an unsupported element set).
>
> --
>
> Archie
>
> -- Archie Warnock                         warnock@...
> -- A/WWW Enterprises                          www.awcubed.com
> --       As a matter of fact, I _do_ speak for my employer.

[Archie Warnock]

Ray Denenberg, Library of Congress wrote:

> Archie, I don't want anyone to change their implementation behavior
> based on the existing or a revised agreement.  So this is useful
> feedback, thanks. I would like to incorporate existing implementation
> practice into the revised procedure.
>
> I think that the 110 record syntax was first registered with the idea
> that the XML schema was known by private agreement.  (Subseqently we
> registered 112 to use in the case when you want to also specify the
> schema.)  It sounds like what you are doing is consisitent with what we
> had in mind.  I'll write this into the revised agreement.
>
> Any other feedback on this is also welcome.

Well, it's more a matter of being ready for any requests that come in.
It's not exactly at the top of my development priority list, but it's
something that Isite ought to handle in accord with the agreement.

--

Archie

-- Archie Warnock                         warnock@...
-- A/WWW Enterprises                          www.awcubed.com
--       As a matter of fact, I _do_ speak for my employer.

[Adam Dickmeiss]

Ray Denenberg, Library of Congress wrote:

>
> Archie, I don't want anyone to change their implementation behavior
> based on the existing or a revised agreement.  So this is useful
> feedback, thanks. I would like to incorporate existing implementation
> practice into the revised procedure.
>
> I think that the 110 record syntax was first registered with the idea
> that the XML schema was known by private agreement.  (Subseqently we
> registered 112 to use in the case when you want to also specify the
> schema.)  It sounds like what you are doing is consisitent with what
> we had in mind.  I'll write this into the revised agreement.

We're pretty much in the same wagon as Archie. AFAIK, we have never used
any other OID for XML than the original one. Most often the element set
name further specifies the requested schema. In other words, like the
(xml-b) implementor's agreement but using the original OID.

/ Adam

>
> Any other feedback on this is also welcome.
>
> --Ray
>
> ----- Original Message ----- From: "Archie Warnock" <warnock@...>
> To: "Ray Denenberg, Library of Congress" <rden@...>
> Cc: <www-zig@...>
> Sent: Monday, January 26, 2009 2:24 PM
> Subject: Re: Requesting XML records via Z39.50
>
>
>> Ray Denenberg, Library of Congress wrote:
>>> I would like to revisit the implementor agreement on "Requesting XML
>>> Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html,
>>> as it
>>> has been many years since it we've discussed it, and it does seem to
>>> warrant some clarification.
>>
>> And note that the link in that page
>> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
>> valid.
>>
>>> Briefly,  to retrieve records according to a specific XML schema using
>>> Z39.50 (if you DON'T want to use compSpec):
>>> 1. XML is specified as the record syntax,  specifically 'xml-b':
>>> 1.2.840.10003.5.112.
>>> 2. The schema identifier is specified as the element set name.
>>
>> Somehow I missed the original Implementor's Agreement and Isite has been
>> happily chugging along without it.  We don't use compSpec in Isite but
>> the majority of uses are homogeneous enough that we haven't had to (nor
>> been asked to) rely on the agreement.  The old XML OID (we've been using
>> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
>> XML we know about - ie, the record we ingested.  This works reasonably
>> well since the schema is usually either known or agreed to a priori or
>> included in the XML anyway, in which case the returned XML is
>> self-documenting and it's up to the requesting client what to do with
>> it.
>>
>> I have no objection to implementing the convention, provided there's no
>> implied agreement to _transform_ records into the requested schema.  My
>> inclination would be to return either the record, if we know and can
>> provide the particular schema or to return an error if we don't (ie, it
>> would be treated like an unsupported element set).
>>
>> --
>>
>> Archie
>>
>> -- Archie Warnock                         warnock@...
>> -- A/WWW Enterprises                          www.awcubed.com
>> --       As a matter of fact, I _do_ speak for my employer.
>
>
>

[Tommy Schomacker]

Hi Adam,

What OID is "the original one"? I have found these OID for XML record syntaxes in the registry:
1.2.840.10003.5.109.10 xml (no specific version)
1.2.840.10003.5.109.10.1.0 xml version 1.0    
1.2.840.10003.5.109.10.1.1 xml version 1.1
1.2.840.10003.5.110 Z39.50 mime types  
1.2.840.10003.5.112 xml-b  XML record according to the schema or definition identified by the element set name.

Best regards
Tommy
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 26. januar 2009 21:58
Til: www-zig@...
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50



Ray Denenberg, Library of Congress wrote:

>
> Archie, I don't want anyone to change their implementation behavior
> based on the existing or a revised agreement.  So this is useful
> feedback, thanks. I would like to incorporate existing implementation
> practice into the revised procedure.
>
> I think that the 110 record syntax was first registered with the idea
> that the XML schema was known by private agreement.  (Subseqently we
> registered 112 to use in the case when you want to also specify the
> schema.)  It sounds like what you are doing is consisitent with what
> we had in mind.  I'll write this into the revised agreement.

We're pretty much in the same wagon as Archie. AFAIK, we have never used
any other OID for XML than the original one. Most often the element set
name further specifies the requested schema. In other words, like the
(xml-b) implementor's agreement but using the original OID.

/ Adam

>
> Any other feedback on this is also welcome.
>
> --Ray
>
> ----- Original Message ----- From: "Archie Warnock" <warnock@...>
> To: "Ray Denenberg, Library of Congress" <rden@...>
> Cc: <www-zig@...>
> Sent: Monday, January 26, 2009 2:24 PM
> Subject: Re: Requesting XML records via Z39.50
>
>
>> Ray Denenberg, Library of Congress wrote:
>>> I would like to revisit the implementor agreement on "Requesting XML
>>> Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html,
>>> as it
>>> has been many years since it we've discussed it, and it does seem to
>>> warrant some clarification.
>>
>> And note that the link in that page
>> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
>> valid.
>>
>>> Briefly,  to retrieve records according to a specific XML schema using
>>> Z39.50 (if you DON'T want to use compSpec):
>>> 1. XML is specified as the record syntax,  specifically 'xml-b':
>>> 1.2.840.10003.5.112.
>>> 2. The schema identifier is specified as the element set name.
>>
>> Somehow I missed the original Implementor's Agreement and Isite has been
>> happily chugging along without it.  We don't use compSpec in Isite but
>> the majority of uses are homogeneous enough that we haven't had to (nor
>> been asked to) rely on the agreement.  The old XML OID (we've been using
>> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
>> XML we know about - ie, the record we ingested.  This works reasonably
>> well since the schema is usually either known or agreed to a priori or
>> included in the XML anyway, in which case the returned XML is
>> self-documenting and it's up to the requesting client what to do with
>> it.
>>
>> I have no objection to implementing the convention, provided there's no
>> implied agreement to _transform_ records into the requested schema.  My
>> inclination would be to return either the record, if we know and can
>> provide the particular schema or to return an error if we don't (ie, it
>> would be treated like an unsupported element set).
>>
>> --
>>
>> Archie
>>
>> -- Archie Warnock                         warnock@...
>> -- A/WWW Enterprises                          www.awcubed.com
>> --       As a matter of fact, I _do_ speak for my employer.
>
>
>

[Adam Dickmeiss]

Tommy Schomacker wrote:
> Hi Adam,
>
> What OID is "the original one"? I have found these OID for XML record syntaxes in the registry:
> 1.2.840.10003.5.109.10 xml (no specific version)
>  
This one:

1.2.840.10003.5.109.10

/ Adam

> 1.2.840.10003.5.109.10.1.0 xml version 1.0    
> 1.2.840.10003.5.109.10.1.1 xml version 1.1
> 1.2.840.10003.5.110 Z39.50 mime types  
> 1.2.840.10003.5.112 xml-b  XML record according to the schema or definition identified by the element set name.
>
> Best regards
> Tommy
> -----Oprindelig meddelelse-----
> Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
> Adam Dickmeiss
> Sendt: 26. januar 2009 21:58
> Til: www-zig@...
> Cc: www-zig@...
> Emne: Re: Requesting XML records via Z39.50
>
>
>
> Ray Denenberg, Library of Congress wrote:
>  
>> Archie, I don't want anyone to change their implementation behavior
>> based on the existing or a revised agreement.  So this is useful
>> feedback, thanks. I would like to incorporate existing implementation
>> practice into the revised procedure.
>>
>> I think that the 110 record syntax was first registered with the idea
>> that the XML schema was known by private agreement.  (Subseqently we
>> registered 112 to use in the case when you want to also specify the
>> schema.)  It sounds like what you are doing is consisitent with what
>> we had in mind.  I'll write this into the revised agreement.
>>    
> We're pretty much in the same wagon as Archie. AFAIK, we have never used
> any other OID for XML than the original one. Most often the element set
> name further specifies the requested schema. In other words, like the
> (xml-b) implementor's agreement but using the original OID.
>
> / Adam
>  
>> Any other feedback on this is also welcome.
>>
>> --Ray
>>
>> ----- Original Message ----- From: "Archie Warnock" <warnock@...>
>> To: "Ray Denenberg, Library of Congress" <rden@...>
>> Cc: <www-zig@...>
>> Sent: Monday, January 26, 2009 2:24 PM
>> Subject: Re: Requesting XML records via Z39.50
>>
>>
>>    
>>> Ray Denenberg, Library of Congress wrote:
>>>      
>>>> I would like to revisit the implementor agreement on "Requesting XML
>>>> Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html,
>>>> as it
>>>> has been many years since it we've discussed it, and it does seem to
>>>> warrant some clarification.
>>>>        
>>> And note that the link in that page
>>> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
>>> valid.
>>>
>>>      
>>>> Briefly,  to retrieve records according to a specific XML schema using
>>>> Z39.50 (if you DON'T want to use compSpec):
>>>> 1. XML is specified as the record syntax,  specifically 'xml-b':
>>>> 1.2.840.10003.5.112.
>>>> 2. The schema identifier is specified as the element set name.
>>>>        
>>> Somehow I missed the original Implementor's Agreement and Isite has been
>>> happily chugging along without it.  We don't use compSpec in Isite but
>>> the majority of uses are homogeneous enough that we haven't had to (nor
>>> been asked to) rely on the agreement.  The old XML OID (we've been using
>>> 1.2.840.10003.5.109.10) is sufficient for us - I just return the only
>>> XML we know about - ie, the record we ingested.  This works reasonably
>>> well since the schema is usually either known or agreed to a priori or
>>> included in the XML anyway, in which case the returned XML is
>>> self-documenting and it's up to the requesting client what to do with
>>> it.
>>>
>>> I have no objection to implementing the convention, provided there's no
>>> implied agreement to _transform_ records into the requested schema.  My
>>> inclination would be to return either the record, if we know and can
>>> provide the particular schema or to return an error if we don't (ie, it
>>> would be treated like an unsupported element set).
>>>
>>> --
>>>
>>> Archie
>>>
>>> -- Archie Warnock                         warnock@...
>>> -- A/WWW Enterprises                          www.awcubed.com
>>> --       As a matter of fact, I _do_ speak for my employer.
>>>      
>>
>>    
>
>
>
>
>
>
>  

[Edward C. Zimmermann]

On Mon, 26 Jan 2009 14:24:24 -0500, Archie Warnock wrote

> Ray Denenberg, Library of Congress wrote:
> > I would like to revisit the implementor agreement on "Requesting XML
> > Records",  http://www.loc.gov/z3950/agency/agree/request-xml.html, as it
> > has been many years since it we've discussed it, and it does seem to
> > warrant some clarification.
>
> And note that the link in that page
>
> (http://www.loc.gov/z3950/agency/zing/srw/records.html) is no longer
> valid.
>
> > Briefly,  to retrieve records according to a specific XML schema using
> > Z39.50 (if you DON'T want to use compSpec):
> > 1. XML is specified as the record syntax,  specifically 'xml-b':
> > 1.2.840.10003.5.112.
> > 2. The schema identifier is specified as the element set name.
>
> Somehow I missed the original Implementor's Agreement and Isite has been
> happily chugging along without it.  We don't use compSpec in Isite
> but the majority of uses are homogeneous enough that we haven't had
> to (nor been asked to) rely on the agreement.  The old XML OID
> (we've been using
> 1.2.840.10003.5.109.10) is sufficient for us - I just return the

Given that we have a lot of common genes to Isite/Isearch--- just
heavily mutated over the years into a new species-- I've been using these
as well..
  {sgmlRecordSyntax,                           "1.2.840.10003.5.109.9"},
  {XmlRecordSyntax,                            "1.2.840.10003.5.109.10"},
  {applicationXMLRecordSyntax,                 "1.2.840.10003.5.109.11"},

> only XML we know about - ie, the record we ingested.  This works reasonably

I, however, don't just deliver the record as ingested unless, of course, the
record ingested was XML or SGML but, if possible, I try to on-the-fly create
a XML "representation"--- or whatever Record Syntax was requested---- of the
record content as "stored" (which, in turns, depends upon how it was
"ingested"). The XML schema/DTDs are, of course, only what they have
wired in. For conversions to other Schemas/DTD--- or even other formats
or variations from those whose Record Syntaxes we handle--- we have a design
that allows for external methods/programs/functions to be specified. This has
gotten a lot of use for HTML within workflow solutions but I don't think
anyone has bothered to use it to get a record based upon a different XML
Schema/DTD from the one normally returned. My wired in XML for eMail is
different from  MarkLogic's but in typical use I don't think it matters to
anyone other than us (and them). I don't quite see the business case for
search-time arbitrary schema conversion requests by users--- and nobody has
ever asked for it and we've had some pretty wild (and ill thought out)
requests over the years :-)

The element set name in our case is the element set (or path to a fragment)
and NOT the schema identifier. In projects were we have needed multiple
schema we have deployed private OIDs like 1.2.840.10003.5.1000.34.3,
1.2.840.10003.5.1000.34.4.1, 1.2.840.10003.5.1000.34.4.2,
1.2.840.10003.5.1000.34.4.3 ...

Paths/Fragments etc. are important to us since we don't always work with
records as the unit of recall but either user specified (directions or paths)
or heuristically (search time) determined paths.

> well since the schema is usually either known or agreed to a priori
> or included in the XML anyway, in which case the returned XML is
> self-documenting and it's up to the requesting client what to do
> with it.
As the original intent :-)


--

Edward C. Zimmermann, NONMONOTONIC LAB
Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
Office Leo (R&D):
   Leopoldstrasse 53-55, D-80802 Munich,
   Federal Republic of Germany
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967

[ray denenberg-2]

If I may, please indulge me as I review some of the history behind all these
object identifiers, etc.  and I hope this may provide some historical
perspective.

When we began to talk about XML for Z39.50 (roughly, ten years ago), we
viewed it (correctly) as a record syntax analogous to GRS-1.  If you don't
remember GRS-1, it is sufficient to say that it was the pre-XML functional
equivalent of XML - a generic syntax, meaningful only when used in
conjunction with a schema and namespace (which Z39.50 called a tagset). This
is in contrast to record syntaxes like the various marcs, which had built-in
schemas and tagsets.

Thus: GRS-1 was a record syntax;  XML was a record syntax. GRS-1 worked with
Z39.50 schemas and tagsets; XML worked with XML schemas and namespaces.

It is also necessary (though painful) to point out that GRS-1 worked also
with "dynamic element specifications", for which there is no real  XML
analogy. These dynamic element specifications were generalizations of the
more "static" element set names; you may recall the specification eSpec-1.
It is necessary to mention this because of the compSpec story:  compSpec was
provided in Z39.50-1995 as a complex alternative to using just a record
syntax and element set name-  "marc" with  "brief", for example.  Compspec
assumed that you would use grs-1 as the record syntax, and also specify a
schema. And in addition, perhaps an eSpec specification.  Then XML came
along at which point compSpec assumed you would use either GRS-1 or XML as
the record syntax, and correspondingly a GRS-1 or XML schema (and if GRS-1,
perhaps also an eSpec specification).

This is boring I know, but it gets a bit more interesting now (or at least
more relevant).

So, we registered 1.2.840.10003.5.109.10 as the record syntax for XML, for
use as just described.   Then someone asked "XML version 1.0 or 1.1"?  So we
registered 1.2.840.10003.5.109.10.1.0  and 1.2.840.10003.5.109.10.1.1 for
these versions and designated 1.2.840.10003.5.109.10 as "no specific
version". Why did we register these version specific identifiers? Because we
thought we had to; we didn't know any better at the time.

 Three things in particular led to the implementor agreement, to use 112 and
put the schema in the element set name parameter.

1.  Very few if any implementors wanted to implement compSpec. There was a
popular cry to be able to simply specify the record syntax as XML and some
way to indicate the XML schema, but without using compSpec.   Of course the
purists (me included) pointed out that this was what compSpec was invented
for!  Not using it would be a cludge! The counter argument was, no, compSpec
was invented for dynamic element specification and nobody is going to
implement it. (The truth was somewhere in between. It was invented for both
purposes.)  And compSpec was too complicated.

2.  After much debate and discussion, the ZIG decided that an element set in
the XML environment is a schema. (A subschema, perhaps, but a schema
nevertheless).

3. There needed to be a clean break from the confusing XML OIDS, 109.10,
109.10.1.0, and 109.10.1.1 which were all supposed to be used with compSpec
anyway.  So we decided to register a completely new OID, 112, to represent
XML for use as described in the agreement.

I hope this helps some.

--Ray

----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; <www-zig@...>
Cc: <www-zig@...>
Sent: Tuesday, January 27, 2009 4:16 AM
Subject: SV: Requesting XML records via Z39.50



Hi Adam,

What OID is "the original one"? I have found these OID for XML record
syntaxes in the registry:
1.2.840.10003.5.109.10 xml (no specific version)
1.2.840.10003.5.109.10.1.0 xml version 1.0
1.2.840.10003.5.109.10.1.1 xml version 1.1
1.2.840.10003.5.110 Z39.50 mime types
1.2.840.10003.5.112 xml-b  XML record according to the schema or definition
identified by the element set name.

Best regards
Tommy

[Adam Dickmeiss]

Ray Denenberg wrote:

>
> If I may, please indulge me as I review some of the history behind all
> these object identifiers, etc.  and I hope this may provide some
> historical perspective.
>
> When we began to talk about XML for Z39.50 (roughly, ten years ago),
> we viewed it (correctly) as a record syntax analogous to GRS-1.  If
> you don't remember GRS-1, it is sufficient to say that it was the
> pre-XML functional equivalent of XML - a generic syntax, meaningful
> only when used in conjunction with a schema and namespace (which
> Z39.50 called a tagset). This is in contrast to record syntaxes like
> the various marcs, which had built-in schemas and tagsets.
>
> Thus: GRS-1 was a record syntax;  XML was a record syntax. GRS-1
> worked with Z39.50 schemas and tagsets; XML worked with XML schemas
> and namespaces.
>
> It is also necessary (though painful) to point out that GRS-1 worked
> also with "dynamic element specifications", for which there is no
> real  XML analogy. These dynamic element specifications were
> generalizations of the more "static" element set names; you may recall
> the specification eSpec-1. It is necessary to mention this because of
> the compSpec story:  compSpec was provided in Z39.50-1995 as a complex
> alternative to using just a record syntax and element set name-  
> "marc" with  "brief", for example.  Compspec assumed that you would
> use grs-1 as the record syntax, and also specify a schema. And in
> addition, perhaps an eSpec specification.  Then XML came along at
> which point compSpec assumed you would use either GRS-1 or XML as the
> record syntax, and correspondingly a GRS-1 or XML schema (and if
> GRS-1, perhaps also an eSpec specification).
>
> This is boring I know, but it gets a bit more interesting now (or at
> least more relevant).
>
> So, we registered 1.2.840.10003.5.109.10 as the record syntax for XML,
> for use as just described.   Then someone asked "XML version 1.0 or
> 1.1"?  So we registered 1.2.840.10003.5.109.10.1.0  and
> 1.2.840.10003.5.109.10.1.1 for these versions and designated
> 1.2.840.10003.5.109.10 as "no specific version". Why did we register
> these version specific identifiers? Because we thought we had to; we
> didn't know any better at the time.
>
> Three things in particular led to the implementor agreement, to use
> 112 and put the schema in the element set name parameter.
>
> 1.  Very few if any implementors wanted to implement compSpec. There
> was a popular cry to be able to simply specify the record syntax as
> XML and some way to indicate the XML schema, but without using
> compSpec.   Of course the purists (me included) pointed out that this
> was what compSpec was invented for!  Not using it would be a cludge!
> The counter argument was, no, compSpec was invented for dynamic
> element specification and nobody is going to implement it. (The truth
> was somewhere in between. It was invented for both purposes.)  And
> compSpec was too complicated.
>
> 2.  After much debate and discussion, the ZIG decided that an element
> set in the XML environment is a schema. (A subschema, perhaps, but a
> schema nevertheless).
>
> 3. There needed to be a clean break from the confusing XML OIDS,
> 109.10, 109.10.1.0, and 109.10.1.1 which were all supposed to be used
> with compSpec anyway.  So we decided to register a completely new OID,
> 112, to represent XML for use as described in the agreement.
>
> I hope this helps some.

I fully to make the implementors agreement for using element set as
schema. I just never understood the reasons to make a new OID. Clients
either use Comspec and use the string arm (Amendment 5) or they use
element set and put schema there.. For our software in both cases we
retained the original OID. The servers, in turn, would see syntax==XML
and look for schema in either the complex spec or element set name..
Semantics thereafter were exactly the same.

As for XML 1.1 or XML 1.0.. 1.0 prevail and I have yet to see servers
that can deliver both types for some schema.

It's also been our assumption that it would be practical to use same
schema identifiers for both SRU and Z39.50. Why have two registries?
Z39.50 is just another carrier for XML.. albeit a much more efficient one:-)

/ Adam

>
> --Ray
>
> ----- Original Message ----- From: "Tommy Schomacker" <TS@...>
> To: "Adam Dickmeiss" <adam@...>; <www-zig@...>
> Cc: <www-zig@...>
> Sent: Tuesday, January 27, 2009 4:16 AM
> Subject: SV: Requesting XML records via Z39.50
>
>
>
> Hi Adam,
>
> What OID is "the original one"? I have found these OID for XML record
> syntaxes in the registry:
> 1.2.840.10003.5.109.10 xml (no specific version)
> 1.2.840.10003.5.109.10.1.0 xml version 1.0
> 1.2.840.10003.5.109.10.1.1 xml version 1.1
> 1.2.840.10003.5.110 Z39.50 mime types
> 1.2.840.10003.5.112 xml-b  XML record according to the schema or
> definition identified by the element set name.
>
> Best regards
> Tommy
>
>
>

[Mike Taylor-10]

Ray Denenberg writes:
 > So, we registered 1.2.840.10003.5.109.10 as the record syntax for
 > XML, for use as just described.  Then someone asked "XML version
 > 1.0 or 1.1"?  So we registered 1.2.840.10003.5.109.10.1.0 and
 > 1.2.840.10003.5.109.10.1.1 for these versions and designated
 > 1.2.840.10003.5.109.10 as "no specific version". Why did we
 > register these version specific identifiers? Because we thought we
 > had to; we didn't know any better at the time.
 >
 > Three things in particular led to the implementor agreement, to use
 > 112 and put the schema in the element set name parameter.

... and let's not even get into Index Data's misappropriation of
1.2.840.10003.5.109.11 to represent application/xml as opposed to
text/xml :-)

 _/|_ ___________________________________________________________________
/o ) \/  Mike Taylor    <mike@...>    http://www.miketaylor.org.uk
)_v__/\  "Cold-hearted orb that rules the night // Removes the colors from
         our sight // Red is gray, and yellow white // But we decide which
         is right // And which is a quantization error" -- ppmtopgm(1)
         manual entry.

[ray denenberg-2]

From: Adam Dickmeiss [mailto:adam@...]
>It's also been our assumption that it would be practical to use same schema
identifiers for both SRU and Z39.50. Why have two registries?


Well the problem is that you have to use the OID form if you are supplying
the schema identifier in the schema field in compspec. You don't have any
choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you could
(technically) use the URI form when supplying it within the element set name
parameter (because it has no such restriction).  So one way or the other you
end up with two different identfiers: either (a) different for SRU and
Z39.50, or (b) different for the two ways within Z39.50. And in the second
case, one of the two will be inconsistent with SRU.  So (a) would be the
lesser of the evils, wouldn't it?

(Or are you suggesting that we use OIDs instead or URIs in SRU. I hope not.)

--Ray

[Adam Dickmeiss]

Ray Denenberg wrote:
> From: Adam Dickmeiss [mailto:adam@...]
>  
>> It's also been our assumption that it would be practical to use same schema
>>    
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.
Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required.  But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

> You don't have any
> choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you could
> (technically) use the URI form when supplying it within the element set name
> parameter (because it has no such restriction).  So one way or the other you
> end up with two different identfiers: either (a) different for SRU and
> Z39.50, or (b) different for the two ways within Z39.50. And in the second
> case, one of the two will be inconsistent with SRU.  So (a) would be the
> lesser of the evils, wouldn't it?
>
> (Or are you suggesting that we use OIDs instead or URIs in SRU. I hope not.)
>  

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>  

[Tommy Schomacker]

Thanks to Ray for the excellent description of the problem and for trying to find a solution.

First and most important. We need a clear specification on how to deal with xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal meets this goal.

Second and also important. It would be nice if the schema identifiers registered for Z39.50 could be valid for SRU too - and vice versa. I think Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50



Ray Denenberg wrote:
> From: Adam Dickmeiss [mailto:adam@...]
>  
>> It's also been our assumption that it would be practical to use same schema
>>    
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.
Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required.  But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

> You don't have any
> choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you could
> (technically) use the URI form when supplying it within the element set name
> parameter (because it has no such restriction).  So one way or the other you
> end up with two different identfiers: either (a) different for SRU and
> Z39.50, or (b) different for the two ways within Z39.50. And in the second
> case, one of the two will be inconsistent with SRU.  So (a) would be the
> lesser of the evils, wouldn't it?
>
> (Or are you suggesting that we use OIDs instead or URIs in SRU. I hope not.)
>  

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>  

[ray denenberg-2]

I agree that using a single form of the schema identifier is preferable, and
that it should be the URI form as used in SRU.

If there is anyone who objects?

If we do that then I would want to cease registering OIDs for new schemas.
We can do that only if nobody is using copmSpec.

So ... is anyone out there using compspec?

--Ray



----- Original Message -----
From: "Tommy Schomacker" <TS@...>
To: "Adam Dickmeiss" <adam@...>; "Ray Denenberg"
<raydenenberg@...>
Cc: <www-zig@...>
Sent: Thursday, January 29, 2009 4:01 AM
Subject: SV: Requesting XML records via Z39.50


Thanks to Ray for the excellent description of the problem and for trying to
find a solution.

First and most important. We need a clear specification on how to deal with
xml schemas and subschemas in Z39.50 and ind SRU. I think Rays proposal
meets this goal.

Second and also important. It would be nice if the schema identifiers
registered for Z39.50 could be valid for SRU too - and vice versa. I think
Rays proposal also will meet this goal if we use URI instead of OID.

Do we need to take compspec into consideration? As I understand it, this is
not used very much and it has no counterpart in SRU.

Best regards
Tommy Schomacker, Danish Bibliographic Centre
-----Oprindelig meddelelse-----
Fra: www-zig-request@... [mailto:www-zig-request@...]På vegne af
Adam Dickmeiss
Sendt: 29. januar 2009 09:10
Til: Ray Denenberg
Cc: www-zig@...
Emne: Re: Requesting XML records via Z39.50



Ray Denenberg wrote:

> From: Adam Dickmeiss [mailto:adam@...]
>
>> It's also been our assumption that it would be practical to use same
>> schema
>>
> identifiers for both SRU and Z39.50. Why have two registries?
>
>
> Well the problem is that you have to use the OID form if you are supplying
> the schema identifier in the schema field in compspec.

Well. the way I read amendment 5, the schema OID became optional.
http://www.loc.gov/z3950/agency/amend/am5.html
A string , member uri, may be given instead.

The CompSpec has recordSyntax in it and that is required.  But that's
not a schema.. So using Amendment 5 we have a way to specify a string
based schema.. Now all this is probably not of interest to many since
it's not widely used, AFAIK.

The element set way.. Page
http://www.loc.gov/z3950/agency/agree/request-xml.html
mentions schema identifiers.. This page even has link to the SRU record
schema identifers.. Although the link no longer works.

My only hope was both that both SRU and Z39.50 would use the same schema
identifiers for XML. Z39.50 has OID based syntax and of course SRU has
recordPacking (but that doesn't affect the schema identifiers).

> You don't have any
> choice there because it's typed as asn.1 OBJECT IDENTIFIER. True, you
> could
> (technically) use the URI form when supplying it within the element set
> name
> parameter (because it has no such restriction).  So one way or the other
> you
> end up with two different identfiers: either (a) different for SRU and
> Z39.50, or (b) different for the two ways within Z39.50. And in the second
> case, one of the two will be inconsistent with SRU.  So (a) would be the
> lesser of the evils, wouldn't it?
>
> (Or are you suggesting that we use OIDs instead or URIs in SRU. I hope
> not.)
>

Of course not.

/ Adam
> --Ray
>
>
>
>
>
>