W3C home > Mailing lists > Public > www-tag@w3.org > February 2010

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

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 5 Feb 2010 16:54:15 -0500
To: Dan Connolly <connolly@w3.org>
Cc: Ben Adida <ben@adida.net>, Jonathan Rees <jar@creativecommons.org>, www-tag@w3.org
Message-ID: <OF300C47AF.1F33DD02-ON852576C1.00770A64-852576C1.007853B1@lotus.com>
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


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Dan Connolly <connolly@w3.org>
02/05/2010 04:19 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     Jonathan Rees <jar@creativecommons.org>, Ben Adida 
<ben@adida.net>, www-tag@w3.org
        Subject:        Re: HTML media type vs. # URIs that do not 
identify document elements


On Fri, 2010-02-05 at 14:47 -0500, noah_mendelsohn@us.ibm.com wrote:
> Jonathan Rees writes:
> 
> > Clearly being out of spec does not seem to be a problem for anyone who
> > does this kind of thing, but it is sort of an embarrassment.
> 
> I can't dispute that it doesn't "seem" to be, but I think I'm right that 

> having HTML fragments used in this way could cause a user agent to do 
the 
> wrong thing, I.e., to attempt to scroll to or otherwise focus on a piece 

> of the document with that identifier.

You say that like it's a bad thing.

i.e. what's "wrong" about that?

>   Though most browsers fail silently 
> when there's no match on a fragid, I don't think it would be 
inappropriate 
> for a browser or any other software to display some sort of "URI doesn't 

> resolve" error message when attempting to dereference such a URI.

Why would browsers do anything different from what they do now?
What do you mean by "such a URI"? All the browser knows is
that it's a URI.

>   So, I 
> don't think this usage is entirely benign.

It's pretty harmless on the hypertext side.

On the semantic web side, you might run into consistencies of
the form "X can't be both an XML element and a Person"... which
is one benefit of the @about attribute in RDFa... it doesn't/needn't
get attached to an XML element.

I go back and forth on this a bit, but for some years I have
leaned toward an update to the HTML media type in this
area.

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

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Friday, 5 February 2010 21:54:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:19 GMT