Re: URLs/MIME only?

At 10:21 PM 12/30/96, Gavin Nicol wrote:
>>   I suppose we could declare a format for "#" strings that encodes our
>>location ladder. In fact, doing so would solve a serious user-interface
>>problem for prospective browsers -- but I am not so sure that new magic URL
>>hackery is really very nice. There is something in this proposal, I think,
>>but it doesn't feel right to me yet. For instance
>
>I have proposed something like this many times. I think a real
>question here is whether to do it as a fragment (ie. the document is
>the primary object) or a pure URL (the element is the object). I tend
>toward the latter. What I proposed was a simple format:
>
>   /foo.sgm/4/2/99                 - Child numbers
>   /foo.sgm/chap=1/sect=2/para=45  - Typed children
>
>This is easy to read, understand, and is useful for things like
>addresses in OODB, and RDB as well.

I think there is a significant advantage for using the # string. (I never
thought I'd say that!)

The location mechanisms we are referring to (element addressing, etc) are
essentailly XML specific (but necessary, despite all that). So it makes
sense that the XML browser should be responsible for locating the sub part
of a document. The WWW has taken several positions that affect this:
     1. A URL is the finest granularity of object that HTTP and browsers
are required to deal with.
     2. That any kind of semantics in a url that is client interpretable
shall only be related to protocol negotiation.
    3. All other semantics in a URL are server-only.
 These positions are slightly modified by # strings:
    4. A client gets an opaque address inside a # string that can be
interpreted to find a sub-part of the addressed resource, possibly based on
the MIME type of the resource.

    This severely handicaps our position with respect to adding locators to
URLs. I have never seen these position articulated in exactly these words,
but the intent is very clear from conversations I have had with Dan
Connolly, Hernik Frystyk, and other W3C notables. I don't necessarily agree
that this is a necessary set of restrictions, but I think we can live
within them.

>>I still wish we were using HTTP headers instead of Processing Instructions
>>(the one SGML feature I have never even contemplated using).
>
>Amen to that!
>
>I was talking to someone who is planning to implement XML the other
>daya, and there is already misunderstanding about what that PI should
>do (ie. can it occur in places beyond the header, and if so, what does
>it do?).

I think it can occur anywhere and do anything, right?

>Headers are headers.... I guess my real avenue for promoting the *.mim
>format is to write a *.mim storage object handler for SP....

   Maybe writing the handler would have a salutary effect! The rest of you
can tune out if you wish, just a little chit-chat among the members of the
choir.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 31 December 1996 13:06:59 UTC