Date: Wed, 23 Mar 1994 09:19:09 -800 (PDT)
From: Mitra <mitra@pandora.sf.ca.us>
Subject: Re: Re URC func spec
To: Michael Mealling <ccoprmm@oit.gatech.edu>
In-Reply-To: <199403231655.AA07643@oit.gatech.edu>
Message-Id: <Pine.3.89.9403230953.D9955-0100000@pandora.sf.ca.us>
> Correct. My objection would against encoding the URN as a field since you
> can accomplish the same thing by allowing a URC to contain more than
> one URN. (If this is objectionable then just consider it as two or more
> URCs that have been stuck together with some rules for what that means).
> Then you can come up with some very flexible fields for what
> relationship that element has to it's previous equal (in the precedence
> sense). One example that Terry brought up offline was something like this:
>
> URN:bla
> TITLE:Mody Dick
> URL:http://bla/bla
> Cost: US$39.95
> URN:bla
> Relationship_Type: Version
> Title: Moby Dick- The Abridged Version
> URL:gopher://bla
> Cost: US$2.00
>
> This allows for two URNs for similiar resources that are not
> considered equal but instead are just similar. It does the same thing as your
> example but is much more parsable. Comments?
Ugggh (you asked for comments). If the secondary URN is data relating to
the first, then it should be on the value side of a tag-value pair, not
hidden on the other side.
I can see a dozen ways of coding this - nested brackets, escaping,
indentation etc, lisp-style etc but dont hide the real structure like
this, or we will just run into other problems later.
- Mitra