HashInURI notes

ashok malhotra wrote:
> just checked in http://www.w3.org/2001/tag/2011/02/HashInURI-20110228.html
> Please review.  Especially sections 4,5 and 6.

some notes..

Generally:

Going back through the TAG issues, this seems to be a long running 
thread which has taken on various guises, for instance ISSUE-37 from 
2003 asks:

   Is it wise to use fragment IDs for identifying abstract components
   within a namespace, even though it is the most natural and convenient
   mechanism? Is there another mechanism that would be preferable?

It appears to me, that over many years there has been a long standing 
general use case, which is for the absolute-URI part of a URI to be a 
namespace, for each namespace to have an unbounded set of local-names, 
indirect references with no pre-assigned meaning who's scope of 
resolution is the namespace, and which can be referenced externally by 
placing the local-name in a fragment and postfixing it to the namespace.

It may be nice for fragments to be defined loosely as above, and for 
media types to offer some well defined ways to bind "things" to 
local-names. For example in the case of HTML, it may offer the ability 
to bind document fragments to a local-name via @id, RDF(a) may offer to 
bind descriptions of abstract concepts to local-names, media fragments 
may offer the ability to bind spatial and temporal media references to 
local-names and so forth.

The difference being, that rather than saying "if a uri contains a 
fragment, and the absolute part dereferences to text/html, then it 
refers to a document fragment, or nothing", it would be saying "if a uri 
contains a fragment, and the absolute part dereferences to text/html, 
and the fragment is bound to an @id within the content, then that 
fragment refers to a document fragment, else it is defined as per the 
generic fragment rules of X".

Perhaps taking this loose definition approach would serve to allow media 
types to offer expected well-defined functionality, whilst allowing 
extensions to the media type to offer their own ways to bind to local 
names (e.g. RDFa), and cater for the evolving usage of fragments with 
javascript in interactive documents and web applications.

Coupling the above to best practise advise on URI collision may be just 
enough to serve the needs to the current web.


next, re: 2.1 Addressing Into Multimedia Streams and 2.2 Media Fragments

It may also be worth considering the youtube use case, where the 
fragment is used to reference a begin-playing-from position of an 
embedded video within the page (rather than referencing an existing 
node, or creating a new one, the frag instead relates to some state of 
an embedded resource). For example:
   http://www.youtube.com/watch?feature=player_embedded&v=RP4abiHdQpc#at=43


finally, General questions that may be interesting:

When has (or hasn't) a new URI with a fragment been minted?
  - when a script adds a new element with an @id at runtime to an HTML 
document?
  - when a script changes the text in an address bar of a browser?
  - when a script offers a reference to a recomposable view state of a 
document or application?
  - when it is found to be referring to something?
  - to what does <script id="foo" type="x/y"> in html refer?
  - what if the media type x/y also has fragment semantics and is 
embedded in <script> tags in an html doc? e.g.
   <script id="foo" type="x/y">
    #bar = { some: data };
   </script>

Should the empty-name-fragment ( a single '#' ) be allowed to be given 
special predefined meaning by media types? does it (or may it) have a 
significant role in web architecture?

Will leave it there.

Best Regards,

Nathan

related: ISSUE-37 ISSUE-40 ISSUE-60 (more..)

Received on Wednesday, 9 March 2011 12:30:07 UTC