> 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>
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.
> 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.
Rob
--
,'/:. Dr Robert Sanderson ([log in to unmask])
,'-/::::. http://www.o-r-g.org/~azaroth/
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Nebmedes: http://nebmedes.o-r-g.org:8000/
____/:::::::::::::.
I L L U M I N A T I
|
