Re: Resource Gloss (Human Readable)

[Jonathan Borden <jborden@mediaone.net>]

Rick Jelliffe wrote:

> From: Jonathan Borden <jborden@mediaone.net>
>
> >     Generally when a user types a URL into a browser there is the
> > expectation that something which makes sense will appear. At a minimum a
> > user who requests text should get text.
>
> How a user request text from a browser?
>
> I certainly don't have that expectation.

    Perhaps not. But directly from the HTTP RFC 2616:
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html]

"12 Content Negotiation
Most HTTP responses include an entity which contains information for
interpretation by a human user. "

and importantly:

"Server-driven negotiation is advantageous when the algorithm for selecting
from among the available representations is difficult to describe to the
user agent, ...
"

What RDDL provides is both human readable and a description to the
user-agent of what representations are available. A representation, in this
case, is unambiguously described by the xlink:arcrole (and the well-known
arcroles as a start are themselves humanely described in RDDL/arcroles.htm.


> If I request a .css or .jpg or .zip
> I don't expect to get a text message.  It is not http:// that implies text
> but  the nominal extension .txt or .html.

    or the Accept: text/css header.

    A way, per RFC 2616, that a user-agent requests text is via the request
header:

    Accept: text/*

    It is not at all clear to me that the so-called problems with
content-negotiation arise because of implementations -- which I suspect --
or rather are from fundamental flaws in the design -- which others have
proffered -- but we've discussed this already and clearly XML-DEV is in
general not accepting of content negotiation as a solution to the namespace
URI 'problem'... probably because its not a solution to the problem of how
to describe a namespace.

>
> (Perhaps RDDL should also define some attribute which can be added to
> documentation elements in extraneous formats to help auto-generation of
RDDL
> directories;
>   <xs:schema ...>
>       <xs:appinfo>
>           <xs:documentation>
>                <html:h1>My Schema</html:h1>
>                <html:p rddl:precis="true">
>                 My schema is so easy that you do not need anything else.
>              </html:p>
>              <rddl:resource .....><html:p>It is an updated version
>              of my last easy and ultimate schema.</html:p></rddl:resource>
>     ...
> )

    Considering this... My main problem is that I generally consider
embedding machine processable out of band information within comment
sections: evil. Unless there is a general expectation to find xlinks and
such within an xsd:documentation element how would XSD software know what to
expect there? While occasionally exceptions to this practice might such as
the inclusion of javadoc directives within java comments is useful and
widely practiced, it would have been even better if such directives had
become part of the Java Language Syntax itself.  I think such a practice
would be acceptable if explicitly included in the XSD specification (not
expecting this :-))

>
> >     RDDL isn't ignoring anyone. I'd say that 99.99% of people who follow
a
> > URI expect to see something in a browser -- and the rest have a true
need
> > for the world to be documented. But seriously, the only rational
argument
> > against an indirection provided by a RDDL document is one of efficiency.
>
> No, another rational argument is that it is not what a sizeable group of
> people actually want and do, and what some specs  (e.g., SOAP) promote.

You make what is 'being done today' sound as a fait accompli. Are you making
a case for the current status quo? Are you making a case for a hardwired and
mandatory resolution of a namespace URI into an XSD and nothing else? Are
you saying that SOAP promotes this? From my point of view, a sizeable number
of people aren't happy with that becoming a defacto interpretation: e.g:

    namespace :== XSD

I don't think most people are saying this. So why would you propose that a
namespace URI resolve into *only* a single representation.

Looking at this another way, suppose SOAP (or 'x' spec for that matter) does
state that messages or documents or whatever be validated against an XSD
resolved through the namespace URI: This doesn't mean that some form of
indirection, negotiation, redirection etc. happens. Resolution of a URI is
handled by software and such resolution can involve indirection.

>
> >     Suppose we provide a servlet which sucks in a RDDL directory on the
> > server and provides a resource based upon an accept header -- forget the
q
> > matching for a moment -- so a client which really does want a particular
> > content type can ask for it, and the servlet can perform the
indirection.
> > For clients that don't care or don't know what to ask for a readable
RDDL
> > document is returned. For those who care, a particular resource format
is
> > returned (and we can indirect on a x-arcrole: header -- or some such
name
> > for an xlink:arcrole URI a client might include in the HTTP GET
request).
>
> ll I am asking for is that the cases where
>  1) there is no RDDL document but a direct resource,

That's up to the server that resolves the namespace URI. What we are trying
to do is reduce the pain associated with documenting namespace URIs *and*
associating related resources.

>  2) that non-RDDL document itself contains <rddl:resource> elements
> are explictly part of the RDDL specification.  In other words, the focus
> should not be on the markup language or the RDDL namespace per se, but on
> how to interpret the retrieved documents from  URI at which one expects to
> find  a related-resource.

 Isn't the content of a non-RDDL document defined by the
specification/schema for the particular document format? Is this akin to
embedding XHTML content in a non XHTML document? Perhaps that would be
generally useful though I'm not sure the world is ready for "Modularization
of RDDL" ... for which I see a serious need for you to complete the proposed
XHTML m12n XSD :-)

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org