- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Mon, 09 Jan 1995 17:53:00 -0800
- To: Terry Winograd <winograd@cs.stanford.edu>
- Cc: hoymand@gate.net, uri@bunyip.com
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>
Received on Monday, 9 January 1995 20:55:49 UTC