From: "Ron Daniel Jr." <email@example.com> Message-Id: <9505190946.ZM5960219@macrdan.acl.lanl.gov> Date: Fri, 19 May 1995 09:46:02 -0600 To: firstname.lastname@example.org Subject: Re: URC defns Cc: email@example.com 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: firstname.lastname@example.org 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"