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

True but insufficient and possibly misleading.  
The reason for having multiple locator types is to 
ensure that one can link into a document where one 
may have read only rights or for example, the format 
is not structured, say a binary image.  HyTime/DSSSL 
designers finally understood that markup is simply 
YetAnotherNotation and made progress on the issue. 
XML is YetAnotherNotation.  The format handler type 
determines the means of resolving the locator but if 
names cannot be supported (what you call an anchor) 
as locators, then other types have to be.  

Encouraging names/ids may be good practice, but not much more. 
Linking into a binary image or a strip of film or even 
a position of a book on a library shelf usually requires 
more than a name.  Not new news.  I do understand the 
maintenance issues of positional and chained locators. 

len

From: Mark Nottingham [mailto:mnot@mnot.net]

+1

Regarding "good policy", I would encourage people to make fragment
identifiers, where possible, refer to 'anchor' style identifiers (i.e.,
using an extensibility mechanism like the 'id' attribute in XML, 'name' in
HTML, and so forth) rather than into the syntax and structure of the
format (as XPointer allows, through use of XPath). Doing so increases the
chance that a fragment identifier could be valid and useful across
multiple formats.

Received on Wednesday, 4 September 2002 13:49:52 UTC