Fragids (Was: Re: Agenda items for next conference call)

On 9 Feb 2013, at 12:28, Marcos Caceres <w3c@marcosc.com> wrote:
> On Thursday, 7 February 2013 at 19:32, Alex Russell wrote:
>> Fragment Identifiers. Jeni and I were able to discuss this off-list last week and I feel as though the TAG could make note about this that contains architectural guidance in both the XML/RDF area and the HTML in a way way that can make everyone happy. Short story: the XML/RDF difficulties spring from an inability for RDF to replace the behavior of xpointer. This arises because the XML processing algorithm does not specify any such extensibility point (nor define itself in terms of such a thing). Tension arises when higher-level semantics must use a low-level representation. The same arises with ad-hoc application-level semantics and HTML; as HTML has not provided a way for changes in fragment identifiers to be handled by "higher level" applications that use it as a representation and wire format, fights break out when apps want to implement a higher-level than "scroll to element" behavior. In both cases, explaining the problem in terms of a lack of extensibility point provides a way to think about the solution

The processing of fragids within RDF/XML is not currently well defined anywhere, so it is not accurate to say that the XML processing algorithm [for fragids] does not specify any extensibility points. The Internet Draft '3023bis' for the XML media types used to state that fragment identifiers had to be interpreted as XPointer and identify elements. This was raised as problematic for RDF/XML (where fragids can be used to identify things like people) and the TAG discussed various ways in which that could be addressed, including special-casing RDF/XML within the XML media type registration itself.

The best practices draft arose from considering how this experience played more generally when fragment identifiers are used based on the syntax of a metalanguage such as XML or JSON, and mixed with fragment identifiers that are used based on the semantics of the particular vocabulary being used with that metalanguage. Hence the best practices aim to encourage those writing media type and structured suffix registrations to both state how fragids should be interpreted (since that's where they're interpretation is supposed to be defined) and be sensitive to the various ways in which documents of those types might be used, including generic processing and content negotiation.

Henry is currently involved in redrafting the Internet Draft for the XML-related media type registrations, which will eventually replace RFC3023.

HTML5's media type registrations [1][2] make it clear that fragment identifiers are interpreted differently for text/html and application/html+xml. There are issues that we could explore to potentially improve both of them:

  * the application/html+xml registration doesn't flag that some fragment identifiers may have application-specific interpretations (eg through scripting), just as they can with text/html
  * neither make any statement encouraging developers to have scripts that interpret fragids behave consistently with the normal interpretation of fragids in HTML, ie that if there's an element with id=foo then #foo should highlight that rather than one with id=bar

It is also worth exploring whether we should act to get the JSON media type definition [3] updated to include the use of JSON Pointer [4].

> I'm wondering if it's possible to extract an Web Dev friendly version of this document? There seems to be potentially good guidance there that Web developers could benefit from, but the current document is inaccessible to the laydeveloper (i.e., me) at the moment - I guess this is because it covers such a wide range of applications of fragment identifiers (most of which most web developers won't ever see or simply don't work in web browsers).  

The majority of the fragids best practices are for people who are writing media type registrations or structured suffix definitions. If you're purely writing HTML, then those parts are irrelevant to you.

However, if you are a web application developer who is writing a RESTful API for an application, then you should(*) be authoring your own media type registrations for the specialised formats that you're using in that API, particularly if you're looking to take advantage of registerContentHandler(), in which case the rest of it should be of interest to you.

So I would like to make it more generally accessible. I'm not sure how to do that, and would welcome both concrete suggestions and actual editing help. Perhaps worked examples would help? Or perhaps there needs to be a separate how-to guide? Or perhaps your needs as a lay developer would be addressed by simply adding some wording in the registrations for text/html and application/html+xml?

Cheers,

Jeni

(*) yes, I know no one does

[1] http://www.w3.org/TR/html5/iana.html#text/htm
[2] http://www.w3.org/TR/html5/iana.html#application/xhtml+xml
[3] http://tools.ietf.org/html/rfc4627
[4] http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-09#section-6
-- 
Jeni Tennison
http://www.jenitennison.com/

Received on Saturday, 9 February 2013 21:53:40 UTC