On 11 Dec 2003 at 15:05, Robert Sanderson wrote:

> > I do not understand the argument. A client receives the record schema
> > that he asked for.
>
> Yes, but the client must be prepared to receive more than one schema.
> 'Must' because the server can return a diagnostic rather than the
> record.
>
> I could then return:
>
> <record>
> <recordSchema>MyShortNameForDiagnostics</recordSchema>
> <recordData>
> ....
> </recordData>
> </record>

I was not aware of the fact that unrequested schemas could be returned. But in that
case I would like to propose to reconsider DCX as a sigificant part of SRU being a short
name to request the server's choice DC based record schema and the other way around
to let the server say: "the record schema that I can provide is not known to you but it
complies to DCX".

>
> And the client would be unable to render the data without access to the
> explain information.
>
> > I would propose to allow short names when the relation between short
> > name and URI is specified in explain. In addition to that I also prefer
>
> It is. (Or will be)
>
> > a short list of short names that is maintained by ZiNG (DC, MARCXML,
> > EAD, ONIX, MODS, DCX).
>
> It is, but they're only suggested not required.
>
>
>
> > Question: how are intelligent clients supposed to use that URI? I
>
> Here's how my stupid client uses it:
>
> <xsl:choose>
> <xsl:when test="recordSchema = 'http://www.loc.gov/...'">
> <b>Schema:</b> Dublin Core
> </xsl:when>
> ...
> <xsl:otherwise>
> <b>Schema:</b> <xsl:value-of select="$schema"/>
> </xsl:otherwise>
> </xsl:choose>
>
> Intelligent clients can do something more intelligent :)
>
>
> > would expect only "known" schemas will be asked for and in case of XML
> > you would rather use a known XSL URI to display a record than a
> > (unknown?) schema URI to validate the record.
>
> Short names can be anything. You'd need to know the explain to know which
> XSL to use.

You know which XSL to use because you have somewhere a table saying which
schema uses which XSL. The server and the schema both do not know which XSL you
have available.
I agree that using URIs give more "precision" but at the same time more divergence. I
belief that different schema's can sometimes be handled the same stylesheet, but by
the increased "precision" the chance of matching becomes smaller. That is the reason
that we will start using DCX at the KB. The overlap in different record types is in case of
metasearches much more relevant to us than the differences. In some applications the
display of elements that are not part of a known schema will be a user option.This only
works when we know that overlapping schemas with different URIs have a short name
in common.

>
> > I assume the terminally braindead clients are web browsers. There is no
> > reason that they cannot have access to explain, and when they have no
>
> If so, then they can also have access to the parameters of the request
> they just sent, and we can ditch echoedRequest. But I can't see how to do
> either without significant Javascript hackery.
>
The echoedRequest is needed to make the response self containing, which allows easy
navigation without much Javascript.
Clients can do a lot but, the more the client wants to do the less security there will be.
We have a broad spectrum of audiences with different browser environments, security
settings and different functional requirements. Access to explain can be done via a
separate browser window (or frame). I do not think you can avoid javascript in this but I
think it can be done without violation of the security.

Theo