Re: Including 'fragment identifier semantics' in MIME media type registration?

On Wednesday, September 4, 2002, 7:49:20 PM, Claude wrote:


BCLL> True but insufficient and possibly misleading.

Agreed. For example, different formats will likely have different
restrictions on the syntax characters, length, or whatever of a "name'
or 'id'.

BCLL> The reason for having multiple locator types is to 
BCLL> ensure that one can link into a document where one 
BCLL> may have read only rights or for example, the format 
BCLL> is not structured, say a binary image.

Yes. Its more fragile than linking direct to a named anchor, but more
useful than linking to the entire document and supplying
human-readable prose that says "in the fourth paragraph of section
5.3.2" or "search for the third occurence of the string "ffoble
widget" in the section entitled "widget types".

BCLL>  HyTime/DSSSL
BCLL> designers finally understood that markup is simply 
BCLL> YetAnotherNotation and made progress on the issue. 
BCLL> XML is YetAnotherNotation.  The format handler type 
BCLL> determines the means of resolving the locator but if 
BCLL> names cannot be supported (what you call an anchor) 
BCLL> as locators, then other types have to be.

Yes.

BCLL> Encouraging names/ids may be good practice, but not much more.

It may be good practice or it may,as you say, provide false hope.

Linking to #sec3.2.3 might well work across resource variants in formats
that allow ascii letters, numbers and periods in their identifiers
(and note that the identifier was probably called sec3.2.3 not 3.2.3
because of XML syntax requirements) and might help me use the same
fragment to get to the HTML and XMLSpec XML variants of one dated
version of a document.

Linking to #widgets-foo-bar might give me a chance of navigating to
the section on widgets, subsection foo, sub-sub-section bar in the
next revision of the document, where an insertion of a new section
caused section 3.2.3 to be renumbered 4.2.3.

It will not help me, if the section on widgets got moved from one
chapter to another and thus, is in a separate HTML file altogether. it
will not help me if the XMLSpec and PDF vdersions are all in one file,
but the HTML version is split into separate files by chapter.


BCLL> Linking into a binary image or a strip of film or even 
BCLL> a position of a book on a library shelf usually requires 
BCLL> more than a name.

Usually, agreed. indirection can help. For example, a SMIL file can
contain a named anchor that in turn sets the presentation of the video
to the time 32 minutes and 25 seconds into a given video clip.

BCLL>   Not new news.  I do understand the
BCLL> maintenance issues of positional and chained locators. 

Yes, they have issues but they are also useful, or better than
nothing. Named locations also have maintenence issues, as noted.

-- 
 Chris                            mailto:chris@w3.org

Received on Thursday, 5 September 2002 09:57:50 UTC