Re: Resource Gloss (Human Readable)

[Rick Jelliffe <ricko@allette.com.au>]

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. 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.   If there is no extension, I
don't have expectations (perhaps I hope for a simple directory listing, but
clearly others expect XSD or some other structural schema).

I don't believe it would be 'best practise" to say that every JavaScript on
the net should have a human-readable precis available, it would be mere
wishful thinking.   There is admittedly more reason to have human summaries
of  namespace related resources, but a single resource of a well-known type
does not need a precis. XML Schemas, Schematon and RELAX all allow/encourage
embedded documentation, so a requirement that there be some minimal
documentation does not hold.

(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>
    ...
)

>     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.

>     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, and also where
 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.

Cheers
Rick Jelliffe