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

I think the usage patter of having the same fragment identifier in RDF
representing typically a non-information resource and having them in html at
the position where a browser should scroll to is really useful.

I agree with Jonathan that this violates the current standards, according to
rdf3986:

"Each representation should either define the fragment so that it
corresponds to the same secondary resource,
regardless of how it is represented, or should leave the fragment
undefined (i.e., not found)."

This means that an HTML representation must not reuse any fragment
identifier used in RDF. However, I think Dan's hypothetical agent shouldn't
complain about broken links without having retrieved all representations
(that one would have to send a request for any content type is another
story).

I think the very useful practice could be made legitimate by changing the
html specs to allow the fragment identifier to designate a resource
described by the corresponding named element.

Cheers,
Reto


On Tue, Feb 9, 2010 at 1:07 AM, <noah_mendelsohn@us.ibm.com> wrote:

> Dan Connolly writes:
>
> > [Noah Mendelsohn writes:]
> > > 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).
> >
> > What failure to resolve? Could you elaborate the case you have
> > in mind?
>
> I'll be glad to try.  I can at least propose something hypothetical that
> might be suggestive of the concern.  Imagine that someone had built an
> agent that helps debug broken links, perhaps for use in conjunction with a
> content management system.  Per the applicable specs,  if
> http://example.com/xyz.html#frag returns text/html, then the URI is a
> reference (or attempted reference) to an element in the file, and the tool
> should include it in a list of broken links if it doesn't resolve.  If
> instead the resource owner uses this as a reference to some other
> secondary resource [2], it will get incorrectly counted as a broken link.
>
> I think this is also in the spirit of the concerns that Eric Bowman
> raised.   I don't know if you'll find this particular example convincing,
> but it's the sort of thing I have in mind.
>
> Noah
>
> [1] http://lists.w3.org/Archives/Public/www-tag/2010Feb/0058.html
> [2] http://www.w3.org/TR/webarch/#def-secondary-resource
> [3]
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Dan Connolly <connolly@w3.org>
> 02/05/2010 06:30 PM
>
>        To:     noah_mendelsohn@us.ibm.com
>        cc:     Ben Adida <ben@adida.net>, Jonathan Rees
> <jar@creativecommons.org>, www-tag@w3.org
>         Subject:        Re: HTML media type vs. # URIs that do not
> identify document elements
>
>
> On Fri, 2010-02-05 at 16:54 -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.
>
> But what you call "damage" looks like stuff working as expected
> and as designed, to me. I don't see the point at all.
>
>
> > 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).
>
> What failure to resolve? Could you elaborate the case you have
> in mind? In the case that Jonathan brought up, there's no
> failure to resolve.
>
>
> >   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
>
>
>
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>
>
>
>