Re: [URN] what's in a syntax? (fwd)

The following is a mail I sent to Leslie regarding her request
on the URN list. I am posting it now, as mentionned before,
because I think that it gives some more background to some
things currently discussed about URNs and URLs. Not that
I think that the things I discuss here should be realized
immediately, though.

Regards,	Martin.

---------- Forwarded message ----------
Date: Tue, 28 Jan 1997 10:01:53 +0100 (MET)
From: "Martin J. Duerst" <[email protected]>
To: Leslie Daigle <[email protected]>
Subject: Re: [URN] what's in a syntax?

On Mon, 27 Jan 1997, Leslie Daigle wrote:

> It seems to me that we are at a crossroads with the URN syntax, and we need to 
> get some concrete sense of direction quickly.
> 
> I'd like to outline the situation below and then ask for everyone to send
> feedback to me directly -- and please, do send feedback, if only to let me
> know people are still thinking about this :-)

Hello Leslie,

I'm definitely still caring about it, although my main concern is
internationalization. Even for this, the syntactic parallels between
URLs and URNs are important, whereas semantically (e.g. why do we
need internationalization), there are wide differences.


> Ryan, our URN syntax document editor, has spent a good deal of time trying
> to get URN syntax to line up reasonably well with the existing URL syntax
> document (i.e., the de facto "URI" syntax document).
> 
> This document is currently under review, and there are efforts afoot to 
> determine a review process for vetting new URL schemes. 
> 
> As part of the discussion of this (on the [email protected] mailing list),
> the issue of URN conformance with URL syntax has come up.  There are some
> specific changes that would (still) have to be made to accomplish this.
> While these are not necessarily stressing in terms of syntax, there
> are some particular ramifications that need to be considered:
> 
> 	. If we align the syntaxes wrt reserved characters, etc, will
> 	  
> 		URN:<see syntax draft of the day>
> 
> 	  necessarily imply that URNs are a "scheme" of URLs?

No, URNs are not, and should not be, a special scheme. They are on
par with URLs. But syntactically, they look like a (not so) special
scheme, and this has many advantages. And they might be processed
by many browsers like a scheme, i.e. look at part before first ":",
decide which subroutine to call, and pass the rest to this subroutine.


> 	  If so, then URNs will have to go through the URL vetting process,
> 	  and potentially the string "URN" will be objected to.

No, URNs are one level higher.

> 	  Also, will this imply that URNs are equivalent to URLs in terms
> 	  of semantics?  (There are those that think the are, and those that
> 	  think they aren't). 

That's not my field of expertise, but I think finally, usage will
show it. In some sense, they are similar (you get something back if
you type it into a browser), in some sense, they are hopefully different
(persistency,...).


> 	. Alternatively, can we align the syntaxes and succeed in having
> 	  
> 
> 		URN:<see syntax draft of the day>
> 
> 	  treated as a special case by URL resolvers, (treated as an 
> 	  opaque URL, as Ryan described it).

An opaque URL, in terms of URLs, is nothing special. A lot of URLs
are opaque URLs, such as "mailto" or "data". URNs conform to URL
syntax. They just don't conform to the syntax for generic URLs,
but that's not necessary.

The question might arise whether relative addressing of URNs is
necessary or desirable. The way I see URNs, their persistency
implies that they are rather big and independent, so that
relative addressing is not of much use. One of the scenarios
I see is that an URN (e.g. for a book) is resolved to an URL
that is the top of the hypertext structure that actually
represents that book, and that that hypertext structure
is internally linked using relative URLs.

This may lead to the question whether we need a way to not only
say "book X" (with urn:isbn:0-12345678-9) but "paragraph m on page n
of chapter y". There would be no need for such things to use
relatively, as other means can be used for addressing inside
a document, and as the main advantage of relative addressing,
invariance under coordinated movement to another place, is
irrelevant because URNs don't change if the actual resource
is moved to another place. But still, the requirement of
addressing a point inside an URN may remain.

The problem is that such addressing can be done in many different
ways (pages vs. chapters and sections, or seconds for a video,...).
The #name feature looks promising, but it restricts references
to only those places that have been tagged beforehand, not a
good thing for maybe very bulky documents.

What I think is worth contemplating, if not already done, are
ways to identify locations inside an URN. This is quite an
architectural question, because we might require that
URN resolvers resolve locations inside a resource at the
same time they resolve the URN itself, or that it is just
something done syntactically. In the first case, an URN
	urn:isbn:0-12345678-9=page34line20
would be passed as
	0-12345678-9=page34line20
to some isbn resolver, which, maybe with the help of other
resolvers, could return an URL such as
	http://xxx.yyy.lib/books/shelfNN/ourBook/chapter3/section2#anchor
which might be the closest identifiable point to line 20 on page 34.
The alternative would be to have an URN
	urn:isbn:0-12345678-9=/chapter3/section2#anchor
which would be chopped apart either by the URN software or an
isbn resolver (depending on whether a generic syntax is choosen
or not). The resolving process would then return only
	http://xxx.yyy.lib/books/shelfNN/ourBook
and the client would append
	/chapter3/section2#anchor
to get the same result. In the above, the fact that the first example
uses lines and pages should not give the impression that this variant
is more oriented towards physical location; the important thing is
that it (potentially) allows various addressing modalities and
transformation from one modality to another. The character "=" has
been choosen just as an example. If we decide that addressing
inside a resource is a desired syntactical property of (potentially)
all URNs and that it should be handled syntactically (i.e. by
string concatenation with the resulting URL, with all the problems
of non-portability), then it might become "#". If URN resolvers
are responsible for this part also, there is no need for a convention,
although it is not bad to have an informal one. The main problem
in this case is that URN schemes have to plan for such things
in advance; it is difficult to start with an "isbn" scheme
without such a feature and later add one. There is also the
danger of fragmentation, i.e. from an isbn scheme, somebody
might create an isbnpageline scheme, whereas somebody else
might create an isbnchaptsect scheme. If done with enough
foresight, this is of course not necessessary, because
	urn:isbn:0-12345678-9=page34line20
and
	urn:isbn:0-12345678-9=chapt2sect3
(which in both cases would need a little bit more of syntax after
the "=") can both coexist.


> These questions have little to do with implementation details -- i.e., 
> any of the above can certainly be implemented.  The real questions, to my
> way of thinking, lie in:
> 
> 	. Does lining up the syntaxes increase the likelihood of getting
> 	  URNs handled sooner rather than later by existing software (i.e.,
> 	  are the necessary differences in handling going to mean that
> 	  existing software can't handle them anyway?)

The syntaxes are already lined up (apart from internationalization issues).

> 	. What issues will we have to address in terms of 
> 	  supporting/distinguishing URN/URL semantics?  (E.g., if URNs
> 	  are supported as URL "schemes",  can we make the distinction
> 	  between names and addresses).
> 
> 
> I have not been successful in trying to make this an even-handed message -- it
> is pretty clear that I am concerned that we are heading back into rough
> waters regarding "why do we need URNs when we have URLs".  _However_, I 
> know there are other people who have seen all of this and think that there
> is no real issue at all.

The rough question might be "do we need some mechanism to identify
'locations' inside a resource".


> So, please send feedback -- if you think there is an issue here, and why, or
> if you think there is no issue here, and why not.  Please send directly
> to me -- I will summarize for the list, and make the collected messages
> available.  

It turns out that I have written a lot here. If you think that it
makes sense to send this directly to the list for further
discussion, please do so or tell me to do so.


Regards,	Martin.