# Re: Library Standards and URIs

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Mon, 09 Jan 1995 17:53:00 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Christopher Fraser: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Paul Hoffman: "Second round for new URL scheme (mailserver)"
- In reply to: Terry Winograd: "Embedded search agents in URLs"

    To: Terry Winograd <winograd@cs.stanford.edu>

    Subject: Re: Library Standards and URIs

    In-Reply-To: Your message of "Wed, 04 Jan 1995 13:58:02 PST."

                 <v03000a12ab30b9594bc0@[192.203.7.234]>

    Date: Mon, 09 Jan 1995 17:53:00 -0800

    From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>

    Message-Id:  <9501091753.aa08489@paris.ics.uci.edu>

Terry Winograd <winograd@cs.stanford.edu> writes:

> Coming into this discussion from a programming-language background rather
> than a library background, I have the feeling that we are slowly moving
> towards something that is already standard in the programming domain --
> extensible collections of class or record definitions. They provide a
> general way to deal with the inevitable tension between the desire for
> simplicity and predictability (wired-in fixed schemes that everyone uses)
> and desire for flexibility (add whatever you need on the fly). ...

I agree with Terry -- much of what has been discussed regarding URCs
would fit better in a truly hierarchical model, where the semantics of
the items can be influenced by their position in the hierarchy
(i.e. inherited from ancestors, etc.). Thus, for something like
URN->URC->URL resolution, I would prefer a syntax like that for PRDM
(see <http://www-pcd.stanford.edu/FRESCO/annotations.html>, with a few
changes, of course ;-) instead of SGML.

However, I would also like to be able to include and identify URC
information within SGML documents. The TEI DTD seems a good start
for that. Although allowing arbitrary DTDs is appealing from an
extensibility point-of-view, it would never work as part of a
URN->URC->URL resolution.

Personally, I don't see why we can't do both (and more). Following the
MIME paradigm, why don't we use media type/subtype and attempt to implement
whatever seems best for a particular application? In other words, define
separate media types for

urc/prdm -- for a PRDM-like URC format
urc/tei -- for a TEI-like URC format
urc/bibtex -- for a BibTeX-like URC format
urc/iafa -- for an IAFA-like URC format
urc/marc -- yikes!
or even
urc/sgml; fpi="-//blech/"

In this way, the format of a URC is independent of the resolution
protocol, and we can let the market decide which one(s) is "best".
Furthermore, it allows us in the Web community to implement client-side
content negotiation on any URI (not just URNs) without any change
to the protocols, and without requiring that the URC be obtained by
a specific protocol.

......Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

- Next message: Christopher Fraser: "Re: Second round for new URL scheme (mailserver)"
- Previous message: Paul Hoffman: "Second round for new URL scheme (mailserver)"
- In reply to: Terry Winograd: "Embedded search agents in URLs"