Re: HTML media type vs. # URIs that do not identify document elements

On Fri, 5 Feb 2010 16:54:15 -0500
noah_mendelsohn@us.ibm.com wrote:

> Dan Connolly wrote:
> 
> > You say that like it's a bad thing.
> > 
> > i.e. what's "wrong" about that?
> 
> > [..]
> 
> > Why would browsers do anything different
> > from what they do now?
> 
> Perhaps I wasn't clear:  I have no problem at all with what the
> browsers are doing.
> 
> I believe Jonathan pointed out a use case in which the semantic Web 
> community was serving text/html documents, with fragids used for
> purposes that were not in conformance with the applicable media type
> specification. You acknowledge that's the issue, where you say:
> 
> > I wrote about this in a 2006 workshop paper...
> > 
> > [[
> > In order for this to work with documents published both in RDF/XML
> > and XHTML, the XHTML media type specifications may need to be
> > ammended so that authors can opt out of the section-of-the-document
> > meaning of fragment identifiers that they publish. For example, the
> > profile attribute from section 7.4.4.3 Meta data profiles of the
> > HTML 4 specification[HTML4] seems like a reasonable opt-out signal.
> > ]]
> >  -- section Fragments as sections vs. people
> >   http://www.w3.org/2006/04/irw65/urisym#docdata
> 
> Right, but there's at least some damage in the meantime, with content
> out on the Web that's in violation of current applicable
> specifications.  I'm not claiming the Web will crumble tomorrow over
> this, but I don't think it's a good thing.  I used the browser
> example merely to point out the kind of damage that might, at least
> in principle, be observed.
> 
> As to amending the media type specification: in principle I might be 
> concerned, precisely because people could have invested in code that 
> interpreted the failure to resolve as an error (at least in the same 
> spirit that 404 is an error).  In practice, it's hard for me to
> imagine that there would be significant trouble for anyone, and
> something like a profile attribute seems like a reasonable way to
> signal the opt-out.
> 
> Noah
> 

Even if @profile is allowed to be used as an opt-out, it's pretty clear
that fragments are intended to *somehow* identify a perspective of the
dereferenced representation, in RFC 3986.  The case Jonathan points to
can be solved with better markup and/or Xpointer, whereas relaxing the
definition of fragment in (X)HTML media types would have an impact
beyond semweb, i.e. by allowing this:

http://www.w3.org/2007/03/html-forms/

Unless those <div class='slide'>s had @ids to match, this practice goes
against established Web architecture and adds a great deal of confusion
to anyone trying to learn what a fragment *properly* does.  Whether RDF
or AJAX, I think many fragment implementations out there aren't
compatible with SVG, even though SVG allows scripting, and could be
used as a variant in content negotiation alongside XHTML and RDF.

The case Jonathan points to could be solved by wrapping those <p>
elements inside of <div>s and assigning the @id to the <div>s.  The RDF
@resource could be changed to an Xpointer referring to the entire
nodeset by the <div>'s @id.  This would not require relaxing any
definitions, be compatible with SVG, and bring the example in line with
RFC 3986 to boot.

-Eric

http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
http://www.w3.org/TR/xpath/#function-id

Received on Friday, 5 February 2010 23:28:40 UTC