- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 8 Feb 2011 11:01:18 +0100
- To: nathan@webr3.org
- Cc: RDFa Working Group WG <public-rdfa-wg@w3.org>
- Message-Id: <818A896B-B26D-4175-B4C4-B284E62297DD@w3.org>
On Feb 8, 2011, at 10:55 , Nathan wrote: > Ivan Herman wrote: >> Would it be possible to ask one of the TAG members a text that would satisfy them? I would hate to spend our time on wording when we have our hands full with other things... > > Sounds like a good idea, because the text/html media type registration specifically says: > > For documents labeled as text/html, the fragment identifier > designates the correspondingly named element; any element may be > named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and > MAP elements may be named with a "name" attribute. > > and we don't use @id or @name. > > We do however allow authors to use URI-references in @href @src @about and @resource, and any of those URI-references may include a "fragment". > > Thus, RDFa allows authors to make RDF statements about URIs which may contain a fragment, but does not provide a way for authors to use fragment identifiers within the media type text/html. > > Due to this, I know I'd personally struggle to write text on this subject since RDFa doesn't use fragids, and prior to a dereferencing attempt URIs are opaque. Indeed. There may be one more additional feature we may want to add to the text, beyond what the TAG might give us: avoid using fragid-s in profile URI-s. That is the only URI that an RDFa processor will dereference, and two different URI-s differing by a fragid only will return the same graph. On the other hand, using two different URI-s for the same graph my make the local caching process inefficient (unless clients would strip the fragid part before caching but I would not expect them to do that...) Ivan > >> I guess Jonathan would be the best candidate. If we agree, I am also happy to contact him. > > Agree (from me), I believe Jonathan has this as action-502 on the tag. > > Best, > > Nathan > >> Ivan >> On Feb 8, 2011, at 02:23 , RDFa Working Group Issue Tracker wrote: >>> ISSUE-84 (Cool URIs and HTTPRange-14): The W3C TAG has asked us to mention that the use of fragment identifiers can be problematic [LC Comment - RDFa Core 1.1] >>> >>> http://www.w3.org/2010/02/rdfa/track/issues/84 >>> >>> Raised by: Manu Sporny >>> On product: LC Comment - RDFa Core 1.1 >>> >>> This is very informal, a formal request will come in a few weeks, but we need to start discussing this before the 2nd Last Call for RDFa Core goes out. >>> >>> Basically the TAG wants to ask the RDFa WG not to fix the RDFa fragid problem, but to document it. >>> >>> That is, somewhere in one of your rec-track (not necessarily 'normative') documents, there should be an explanation of the issue (fragid use implicitly encouraged by RDFa specs, but not described in any media type registration), as a sort of warning and disclaimer. Not to tell people don't do it, but to alert everyone that there's an issue with the specs. >>> >>> Then maybe someone later can come along later and clean things up by fixing 3986, AWWW, the registrations, or something else. >>> >>> The goal is for it to be possible to start with RFC 3986 and find through a sequence of normative documents some statement of what the fragid means. In the case of an important RDFa practice this isn't possible - you look at the text/html or application/xhtml+xml media type registration, and they have stories about fragids that don't include the RDFa use. >>> >>> >>> >>> >> ---- >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> PGP Key: http://www.ivan-herman.net/pgpkey.html >> FOAF: http://www.ivan-herman.net/foaf.rdf > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 8 February 2011 10:00:45 UTC