- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 17 Oct 2011 13:04:54 -0700
- To: www-tag@w3.org
Jonathan: I would vote for d) i.e. document both in RDFa Core and the relevant media types. As re. the conflict between spec re. frag id processing, I would pursue the other thread we have discussed and write a note as a companion to 3896 that explains that frag id processing is influenced by the context and the agent. All the best, Ashok On 10/17/2011 11:50 AM, Jonathan Rees wrote: > ACTION-509 > > The question is what, if anything, would we like for the RDFa > Core 1.1 specification to say about fragment identifiers. On Thursday > I volunteered to come up with more options, and here they are. > > Why should it say anything at all? Because documents utilising RDFa > Core will use fragment identifiers with the same semantics as in other > RDF serializations, and this should be documented somehow. There are > two reasons to think this even though the spec doesn't call it out. > The first is examples like the following: > > <p about="#bbq" typeof="cal:Vevent"> > I'm holding > <span property="cal:summary"> > one last summer barbecue > </span>, > on > <span property="cal:dtstart" content="2015-09-16T16:00:00-05:00" > datatype="xsd:dateTime"> > September 16th at 4pm > </span>. > </p> > > The other reason is that users will simply proceed to assume this > semantics, and it will be supported by processors. They won't ask > permission and won't need encouragement. > > I think the question can be put as follows: > > Is RDF-style fragid semantics for RDFa Core to be documented > > (a) only in the RDFa Core spec, > (b) only in media type (or namespace?) registrations referencing RDFa > Core, > (c) neither, or > (d) both? > > Note that "documented" could be via a chain of normative references, > e.g. by reference to RDF Concepts, which is what RFC 3870 does. > > The WG wants (b) to push it off to the media type registrations - even > though their examples depend on it - with a brief informative note > such as the one that's in the editor's draft. > > For (b) and (d), RDFa Core could give this advice: > > "Those preparing registrations for media types that support RDFa > Core are advised not only to reference RDFa Core but also to > document this style of fragment identifier semantics, following the > example of RFC 3870 section 3." [for "this semantics" see their > current note, prior to 2.1] > > This might help going forward, but does not really do the trick for > current users. It would be helpful to say something about particular > existing registrations, and revisions to those in progress. Might we > want to alert people to these, as a "health warning"? > > "As of the time of publication, the media type registrations for > text/html and application/xml are under revision. We expect RDFa > Core to be referenced (perhaps indirectly) by the text/html > registration, but are not sure what the registration will say about > fragment identifier semantics. The current application/xml > registration (RFC 3023) is compatible with use of RDFa Core [?] and this > fragment identifier semantics, but the relation between the three > going forward is under discussion." > > That's pretty horrific prose. I'll try to wordsmith in background > but didn't want to delay sending something. The problem is that > it tries to deal at the same time with connecting media type to > RDFa Core, and connecting fragids to RDF-style, while hedging > around FYN being helpful but not required. When Core and fragids > are specified in different documents you just have a mess. > > This is starting to sound like an appendix. > > One might also say something about application/xhtml+xml, but I'm not > sure what it would be. > > > From what I understand the situation with text/html is pretty good and > we're on good ground saying so, but I'm not sure what to say about XML > as we have no information. 3023bis might end up being incompatible, > compatible but without FYN, or compatible with FYN. What I wrote > seems to be telling people NOT to serve XML that uses RDFa Core with > media type application/xml until things settle out. Is that really > the message we want to send? If not, is there any other message we > can send? Can we in good faith tell them that it's going to be OK? > > N.b. IF we think that the current 3023bis draft sets up a real > conflict with RDFa Core, then the 3023bis draft is also in conflict > with deployed XHTML+RDFa 1.0 content - of which there is tons - and I > don't see how the 3023bis editors can ignore that. That is, deployed > content either makes 3023bis untenable, or it forces us to admit that > RDF Concepts is right and RDF fragids simply aren't subject to what > the media type registrations say. > > For (a) and (d), RDFa Core would have to add normative language about > fragment ids, i.e. that in an RDFa-Core-conforming document, fragment > ids have RDF-style semantics. (The spec-ese language would have > to be crafted and I won't attempt it now > since it hasn't been on our radar.) This would be going well past > issuing a "health warning" - it would be a substantial new provision > of their specification. > > There is probably no need for (d) since the Core spec could document > fragid semantics; but documenting in both places would be good > citizenship. > > Answer (c) shouldn't be dismissed out of hand; here's the case: (I > don't buy any of this, just trying to make sure it's heard) > > RFC 3986 only says the interpretation "depends on" the media type; > that is too vague to be construable as a requirement for FYN. > Fragid semantics could depend in some obscure way, it could depend > on other things as well, and so on. > > RDF Concepts seems to imply that the FYN story for RDF is different > from that of 3986, and that media types are not really involved > after all. That is, it says that for RDF, you get an > application/rdf+xml representation (or you imagine doing so), then > look at the triples to see what they say. > > Among existing media types the only one that connects fragids to > RDF-style semantics is application/rdf+xml. text/n3, text/turtle, > and other RDF media type registrations say nothing. > application/xhtml+xml handles RDFa via the XHTML namespace > declaration, but the RDFa specification cited by the nsdoc says > nothing about fragid semantics. (There is a non-normative reference > to a GRDDL transform, but the wording is too weak to make a good > connection.) > > Some consider RDF-style FYN to be handled simply by interpreting the > document itself. If you read in a text/plain representation a > sentence that says "The URI '#wh' identifies the White House", > shouldn't you take the URI #wh as identifying the White House? That > is, why should the content itself be any less believable than any > other aspect of the document, in this regard? > > --- > > There is the other, more serious issue we raised, which is what to > do about potential conflicts between specifications of fragment > identifiers (e.g. between RDFa Core and the application/xml media type > registration). We can declare that they're not really conflicts > (similar to what RDF Concepts does). We can observe that there are > conflicts and ak that the conflicts be documented. We can get > involved in the process reconciling them. > > I don't consider this to be important for the question at hand (what > RDFa Core should say). It may be important, and we should encourage > interaction between RDFa Core and 3023bis, but this particular problem > is simply not raised by their document. If people are moved to think > about fragid FYN, then potential conflicts will become prominent > pretty quickly. If they're not then there's not much we can do > anyhow. > > --- > > For reference here is the complete "health warning" in the current > RDFa Core editor's draft: > > In some of the examples below we have used IRIs with fragment > identifiers that are local to the document containing the RDFa > fragment identifiers shown (e.g., 'about="#me"'). This idiom, which > is also used in RDF/XML [RDF-SYNTAX-GRAMMAR] and other RDF > serializations, gives a simple way to 'mint' new IRIs for entities > described by RDFa and therefore contributes considerably to the > expressive power of RDFa. Unfortunately, this practice is not at > present covered by the media type registrations that govern the > meaning of fragment identifiers (see section 3.5 of the URI > specification [RFC3986], [RFC3023], and [RFC2854]). For more > information about fragment identifier semantics, see [WEBARCH] > section 3.2.1. > > There are four sentences here. I think the first two are fine (for a > note) and can stand - they establish what "this fragment identifier > semantics" means. I suggest the third and fourth be deleted and > replaced by either, neither, or both of the two "health warnings" > above, or variants thereof. > > The reference to webarch is not helpful. > > > --- Notes and references --- > > - RDF Concepts has a rather bizarre explanation of fragid semantics > that may or may not be in conflict with 3986 and/or AWWW and/or > the current opinions of TAG members. > > http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID > > - TAG ACTION-130: Consult with Dan and Ralph about the gap between > the XHTML namespace and the GRDDL transformation for RDFa > > http://www.w3.org/2001/tag/group/track/actions/130 > > - RDFa + FYN discussed at Sept 2008 F2F. The proposed change to the > XHTML namespace document was carried out, but it does almost > nothing to address fragid FYN. > > http://www.w3.org/2001/tag/2008/09/24-minutes#item01 . > > - Discussion at May F2F. TAG consensus that the RDFa Core document > should have a "health warning" about fragids. > > http://www.w3.org/2001/tag/2011/05/05-minutes.html#item05 > > - The current RDFa Core editor's draft, which is very close to LCWD. > The requested "health warning" is there, right before section 2.1. > It's the outcome of interactions between JAR (on behalf of TAG) > and the WG. > > http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html > > - Noah didn't like "at present" as it sounded like a promise and no > one is promising. I agreed and proposed that we have them remove > "at present". > > - Henry (and others) were still uneasy and asked for more options. > [insert reference to 13 Oct 2011 telcon minutes] > > - HTML+RDFa > > http://www.w3.org/TR/rdfa-in-html/ > > Jonathan >
Received on Monday, 17 October 2011 20:05:29 UTC