Date:         Tue, 20 Nov 2001 07:49:34 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "LeVan,Ralph" <[log in to unmask]>
Subject:      Re: Extensible and record formats
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Sorry, but I just don't forsee the packaging problems that Alan does.
Sticking XML in XML does not require binary encoding.  Sticking MARC in XML
would require binary encoding, if we permitted it.  But, we've already said
that we will only support the XML record syntax in our responses, so the
only MARC we'll be sending is some translation of MARC to XML.

If you're interested in a really generalized syntax like GRS-1, you should
look into RDF.  You can do anything in RDF that you could do in GRS-1 and
it's XML besides.  While I'm not interested in doing that, you could
certainly support a record schema in an SRW request that used RDF.

Ralph

> -----Original Message-----
> From: Alan Kent [mailto:[log in to unmask]]
> Sent: Monday, November 19, 2001 6:35 PM
> To: [log in to unmask]
> Subject: Extensible and record formats
>
>
> There are different ways extensibility can be achieved. I guess its
> a question of the importance of extensibility versus an interopable
> spec. I think one of the problems with Z39.50 is that it is so
> extensible. This means that both ends have to support all of the
> same concepts. It would be *nice* if it could be agreed what a
> record is. For example,
>
>     A record is always XML markup
>
> or define a GRS-1 like fielded structure and always use that
> (my preference).
>
> If you were going to return a string, I would rather make it Binary.
> That way it could be a XML document, a MARC record, a GIF, etc.
> Strings do not allow all possible characters (only what is legal
> in an XML document). Most control characters for example are not
> permitted. A MARC record for example would not be legal to return
> as a string. It would include invalid XML characters.
>
> If you are going to define a SOAP API (which I think is great),
> then I think it should support WSDL - if only because most of the
> SOAP market are using WSDL files. To me one of the great objectives
> is to get every Microsoft desktop being able to access a Z39.50
> server (via a SRW gateway). Microsoft are big into WSDL files though.
>
> Note that there have been lots of discussions about how to embed
> XML in XML. Due to the potential of different encodings (UTF-8
> for SOAP packet but UTF-16 for embedded document), SOAP not permitting
> processing instructions in the markup, etc, the safest way
> (unfortunately) to embed XML in XML is to use something like
> base64 encoding! (that is, binary)
>
> This is why I quite like the idea of defining, in a WSDL file,
> a GRS-1 like record structure. Eg: define the record structure
> in WSDL as an array of fields. Fields have names, mime type,
> and a choice of a small number of types for the value (string,
> integer, float, boolean, binary). The names could be structured
> in some way to allow dublin core names, nested structures, etc
> to be represented (eg: not just "title", but "dc:title[1]",
> "dc:title[2]", etc for a repeating field). That way a simple
> record with string fields can be represented in XML and viewed
> directly via a web browser, but it can still hold binary data
> for a GIF in the same record. You have your extensibility by
> using Binary fields with strange mime types. But the basic
> concept of a record is very simple.
>
> I would even avoid allowing nested records in records. Encourage
> the use of field names containing paths ("author/first-name").
> Just makes binding to diffferent programming langauges easier.
> A record is a series of uniquely named fields.
>
> I would then drop the record schema. The response schema I guess
> can ask for 'dublin core' - ie provide some control over how
> the data should be returned - eg: what field names to use.
> But there would only be one record structure.
>
> Alan
>