Re: URC defns

Thus spoke Renato Iannella:   (at least on May 19 at 12:17pm)


> Hi, I have been looking at the syntax of URCs and need
> to clear up some issues. The only "internet-draft" proposal
> I have seen is the "Trivial URC Syntax: urc0" by Hoffman
> and Daniel - This proposal seems to return marked-up
> URLs for the user/browser to decide which one to access.

Yes, the intent of that draft is to have a URC syntax that is
dead-simple to parse. It is not intended to be a general URC
syntax.

> Others I have read about include a series of Attributes and values
> (some following the Text Encoding Initiative).

Michael Mealling had an ID for a URC syntax that used 822-style
attribute:value pairs and precedence rules. After the beating he
took at the San Jose IETF, no-one is about to suggest a general
syntax that doesn't explicitly indicate hierarchy. 

He and I have looked at the TEI Independent Header, which is pretty
nice. However, it is not appropriate for resources that are not like
documents (such as multi-resolution image database browsers, and other
dynamic means of access to numeric datasets). Furthermore, even for
resources that are very much like documents, the origin of TEI in the
humanities has led to requiring a few things (like "source" and the
"analytic, monographic, and series" levels of description) that are not
appropriate for most documents prepared electronically.

> Question - will there be a series of URC syntaxes?
> If so, will this be confusing for the browser to decide,
> since the URN will point to an unknown number of possible
> URC specifications? - Or does the URC identify itself (typeing)
> so the the user/browser can then decide to handle it or just 
> return the URC spec.

I am preparing an ID for a URC spec now. It is not far enough along
to reveal the URL to this list, but it does address just this question,
so let me talk about that.

The spec is based on the fundamental assumption that there will be
such a wide range of info put onto the net, and people will want to
describe the same resources in such a wide range of fashions, that there
are NO universally applicable attributes (such as Author). Furthermore,
the scenarios document has requirements on the URC encoding that are
essentially impossible to satisy simultaneously  (a printable representation
that can be cut and pasted and mailed about is NOT going to be suitable
for digital signatures). To accomodate these problems, the URC spec will
distinguish between the URC semantics and the URC syntax, and make both
of them configurable.

First, lets deal with syntax. I favor using HTTP as the protocol for
the URC service. There are a TON of implementations, browser writers
will have an easy job adding URN support, and it provides the Accept:
header. I would like to use the Accept header to negotiate the "transfer
syntax" of the URC. In other words, URC info is held in a database on
the URC server, and it can emit that info in a variety of forms. It
might emit it in text/urc0, text/plain, text/html, or some binary
protocol suited for digital signatures (call it application/urc2 for
the sake of argument). So, if I have a browser that is not capable
of handling URCs automatically, I can request that the info come
back as HTML, which would mean that the URLs would be made into
anchors so I can click on them to get the resource. Sometime during
the summer I want to write a CCI client that will parse text/urc0
and tell the browser to fetch a particular URL. Once that has been
written, I will want my browser to tell the URC server that it will

Accept: text/urc0; text/html; q=0.5; text/plain; q=0.1

i.e. send me urc0 if you can, HTML is second choice, will take plain
text if that is all you can do. Plain text has no defined syntax
for parsing.

So, that is what I will propose for the syntax of a URC. What about
semantics? Recall that I said the URC info would be held on a database
on the URC server and emitted in whatever syntax was requested (and
that the server knows how to generate). The semantics of the URC are
analogous to the database schema.  If I have a site with lots of
satellite images, I would want the URC to contain things like lat/lon,
wavelength(s), image size (rows, cols, bands, bits/band), etc. The
database schema for storing this info will be different than if I had
a site with lots of poetry, where I would want to store author,
number of stanzas, metric scheme, etc.  Rather than calling these
things database schemes, they are referred to as the "attribute set"
of the URC.

A few months back I made a strawman proposal that URCs identify their
attribute set by providing the URN of an SGML DTD fragment that specified
the elements which could be in the URC. No-one seems to have tried to
set that strawman ablaze, so that is pretty much the mechansim that is
used to identify the attribute set. The URC spec will provide a default
attribute set that is beleived to be broadly useful (the Dublin-1 set
for those of you who know about it). People will be able to specialize
that set for their own particular needs in a single inheritance hierarchy.
People can create whole new attribute sets if they want to.


> Question - is the URA proposal just another URC?

I had not really thought of URCs as executable specifications, which is
what URAs are about.


> Question - we would like to create a URC spec for query-able
> information sources - should it be a URC or should we define a
> URQ (that is specific for information sources that provide
> a query interface - as opposed to a "traditional" URC that seems
> to favour static documents)

I think that the URC spec will provide enough capability that you will be
able to describe dynamic resources with it. There is a need for a more
capable query language that would be broadly understood, but that is
a seperate issue from the one of URC description.

> Thanks for your time...

You are welcome.  :-)


-- 
Ron Daniel Jr.                     email: rdaniel@lanl.gov    
Advanced Computing Lab             voice: (505) 665 0597
MS B287                              fax: (505) 665 4939
Los Alamos National Laboratory      http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM  87545          tautology:"Conformity is very popular"

Received on Friday, 19 May 1995 11:42:18 UTC