RDF-in-XHTML Task Force

 

<TomB> just listening (muted)

 

<Ralph> previous non-meeting

<Ralph> previous 2009-01-22

Action Review

ACTION: [DONE] Manu to create design tests for @prefix and @profile. [recorded in http://www.w3.org/2009/01/22-rdfa-minutes.html#action16]

Manu: see my mail
... I showed a first pass of three styles of markup

ACTION: [DROPPED] Ben to add public-rdfa examples to wiki and think of slightly improved top-level organization [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action11]

Ben: I did a reorganization of the wiki then Manu added way more than this action required

ACTION: [CONTINUES] Ben to put up information on "how to write RDFa" with screencast possibly and instructions on bookmarklet. [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action12]

ACTION: [CONTINUES] Ralph or Steven fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01]

ACTION: [CONTINUES] Jeremy to demonstrate GRDDL with XHTML/RDFa once the NS URI is set up. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action03]

Ralph: drop this?

Ben: I'd like to ping Jeremy; I'd like to see this

ACTION: [CONTINUES] Manu to create TC to test @resource="[]" does not set object based on TC 123. [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action14]

ACTION: [CONTINUES] Manu to look at http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Dec/0037.html [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action15]

Manu: I sent an email, no response yet

ACTION: [CONTINUES] Manu to write summary for Semantic Web Use Cases for Ivan. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action09]

ACTION: [CONTINUES] Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12]

ACTION: [CONTINUES] Mark to review reasoning on setting explicit about="" on HEAD and BODY [recorded in http://www.w3.org/2008/12/18-rdfa-irc]

ACTION: [CONTINUES] Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11]

ACTION: [CONTINUES] Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13]

ACTION: [CONTINUES] Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action14]

ACTION: [CONTINUES] Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]

@prefix, specifically @prefix on HEAD

Ben: I'd like to talk about this in concert with the test cases

[[
I see from the discussion on January 22 that there was talk of allowing
@prefix on HEAD to apply to the BODY, but I think we had clearly said in
prior discussions that this shouldn't happen, because of the SAX-based
processing of documents. We need to clarify this.
]]
-- Ben, in email

Ben: am I correct in my interpretation of that 22-Jan discussion?
... @prefix on HEAD would apply to BODY also?

Manu: yes, that was the discussion
... we didn't get too deeply into this
... Mark did propose this would be nice

<msporny> rdfa-test-harness/

Manu: there are 3 variations on @prefix syntax
... select 'Design Test Suite' and 'Unreviewed'

<ShaneM> "We will serve no predicate before its time"

-- test 9001: Establishing @prefix on HTML element

Manu: the purpose of these tests is just to provide a starting point for the design discussion

<msporny> http://rdfa.info/wiki/design-suite

-> explanation of purpose of test 9001

Manu: 9002 shows a CSS-like syntax, 9003 shows an '=' syntax
... I prefer the '=' syntax, as does Toby Inkster

Ben: three decisions; what to call this @ttribute, what's the value syntax, what's the parsing model

Mark: sounds right. the name is the least important

Ben: the 3 test assume @prefix for the name and the same parsing model as @xmlns
... they're testing for the value syntax options

Manu: correct

Ben: note that none of this discussion is really in scope for this Task Force
... we're producing some notes on how to proceed
... should we make a decision, or should we just note these options and leave it to whatever group is chartered to decide?
... people who do implement these sorts of things tend to implement quickly
... Manu's already done something, as has Ivan
... if we agree amongst ourselves this is a big step
... could be a Note for a year or so
... this would at least put it 'there'
... already some useful discussions around named graphs
... it would be good to converge on a way of approaching these even if we don't have a place to put the formal state of this convergence

<msporny> +1 for going as far as we can with the syntax for @prefix

Ben: so we might proceed on the understanding that whatever we 'decide' can be overturned later

Shane: we're likely to be participants in whatever discussion is chartered
... the XHTML2 WG can proceed now if it chooses
... addition of @profile to the XHTML module would be covered by our current WG charter

Ralph: the SVG folk are pushing on @xmlns support in HTML as well
... SVG Tiny has fully incorporated RDFa
... and SVG itself uses @xmlns

<msporny> When Doug and I were talking at WDN09 - I found a wierd issue with him using xlink:href to specify hrefs in his SVG - it would break a RDFa parser as he marked it up.

Ralph: so are we diluting our message if we add a syntactic alternative?

Mark: it doesn't hurt to have both @xmlns and @prefix in the same document
... we consciously left open this scope in the CURIE spec
... the wording says that XML documents should support @xmlns
... but leaves open the possibility of alternatives

Shane: CURIE is Candidate Rec
... it is correct that alternative mechanisms are permitted by the CURIE spec
... the CURIE spec itself does not define any attributes
... the XHTML2 spec defines the mapping mechanism

<Zakim> ShaneM, you wanted to discuss xmlns: and XML parsing rules

Shane: there's been a good argument in the recent days about why @xmlns: is not isomorphic w.r.t. processing model between HTML5 and XML
... if we say that the attribute name "xmlns:foo" should be treated as a token,
... the truth is that in the XML DOM a real parser should not be passing this token through
... the actual name of the attribute is 'foo' in the XML namespace, not a string 'xmlns:foo'
... @xml... is a reserved namespace

Mark: doesn't the API allow the application to retrieve the full name of the attribute?

Manu: I thought Henri was specifically referring to XOM
... the level 1 API would be fine but the level 2 API would filter xmlns:foo to something else

Mark: but the argument was that an HTML5 processor _would_ give access to the full xmlns:foo whereas an XML pipeline would not
... so why would an application that wants the full string use such an XML pipeline?

Manu: the point was that the cost is not zero as we've claimed

<msporny> +1 for prefix instead of xmlns:

<markbirbeck> +10

Ben: independent of Henri's argument, do we feel that adding @prefix would be prefereable

Ralph: are you just talking about a synonym for @xmlns for CURIE prefixes?
... or the added features of the value that are under discussion?

Mark: if we hadn't chosen @xmlns we'd be in deeper trouble

Ben: there's an argument that @xmlns is working better than expected; we _can_ actually get to it in the browsers

<msporny> me agrees - we needed to use xmlns: for XHTML, but we should provide @prefix as an alternative.

Ben: there's another argument that even if it is working it comes at a cost and we should move to @prefix anyway

Ralph: but what _are_ the costs? I see huge costs in destabilizing a spec

Mark: we're also talking about changing the processing model a bit
... currently we don't provide a way to import a bunch of mappings
... my main argument in favor of a new attribute is to add a feature to come closer to [the simplicity of] microformat

Ben: I was trying to separate the two issues; new features vs. name

Ralph: I don't think you can separate these questions now

Mark: namespaces have never really been resolved in terms of attribute contents
... so with a new attribute we could avoid some of the mistakes of namespaces

Ben: so if @prefix works exactly like @xmlns, are you leaning to preferring it?

Manu, Shane: yes

Manu: we're not talking about removing @xmlns; that would destabilize it
... just adding @prefix as an alternative

Mark: the RDFa spec says that if @xmlns: is present, it should be processed
... we'd still process both @xmlns and @prefix
... in the CURIE spec I'm pretty sure we require that XML processors support @xmlns

<ShaneM> CURIE spec says "When CURIES are used in an XML-based host language, and that host language supports XML Namespaces, prefix values MUST be able to be defined using the 'xmlns:' syntax specified in [XMLNAMES]. Such host languages MAY also provide additional prefix mapping definition mechanisms."

Ben: in terms of the spec, we don't talk about HTML documents currently so I think we're safe adding @prefix
... we do have to talk about the precedence of @xmlns and @prefix
... if we specified that @xmlns has precedence then we'd have a level of backward compatiblity for old XHTML parsers

Mark: sort-of; new parsers would generate more triples but the triples generated by an old parser would match that same subset generated by a new parser

Ben: a note from this TF suggesting that @prefix is a way forward would carry some weight

Mark: we could argue that @prefix is a token substitution before the RDFa processing is invoked

<ShaneM> XHTML 1.2 could introduce @prefix

Ben: but that would mean that the RDFa Recommendation no longer is sufficient to implement an RDFa processor

<msporny> who's working on XHTML 1.2, Shane?

Mark: if @prefix is not introduced by some group with some authority then the HTML WG [might not give it any attention]
... the XHTML2 WG could give this a home and then in the future we harmonize the two

Ben: test cases using @prefix would have to live somewhere

Mark: could be on a Wiki
... a Last Call comment on CURIE would allow the XHTML2 WG to be on the record
... as supporting it for some future version

Ben: do we want to say that RDFa parsers should start supporting @prefix soon?
... if we want @prefix to be supported in both HTML and XHTML
... so we'd recommend that new markup use @prefix instead of @xmlns
... so some document at some time in the future should say how to write such a new RDFa parser

Mark: given our recent experience of HTML5 discussions, it's asking for trouble if we base this on trying to find some accommodation
... whereas if we say we really believe this [independently], we have a stronger argument

Ben: sounds like we'd want to update the RDFa specification to add @prefix to it

<ShaneM> I think that we could successfully do this as a "PER" second edition of RDFa Syntax 1.0

Ben: @xmlns would still be supported

Ralph: it would be harmful for this group to push for XML documents that do not conform to the W3C Recommendation
... so I am opposed to adding @prefix without updating the Recommendation
... the cost of updating the Recommendation could be justified if the update included new features as well
... a possible new feature is the value syntax for @prefix

Shane: the XHTML2 WG could update the RDFa Recommendation

Ralph: yes, that's plausible

Ben: so wiki pages, test cases, etc. should have large disclaimers right now saying @prefix is experimental
... path forward could be to keep this discussion in the wiki as experimental, talk with implementors, work out details in the experimental wiki page

Manu: yes

Mark: I'm a bit uneasy as there are documents being circulated that look like specifications when they should really be blogs
... and the wiki might start to look like a specification too
... the wiki shouldn't imply that we all agree on the content

Manu: you want more than the "experimental" note on the wiki pages?
... "the existence of this page does not imply ..."

Mark: might be worth having a higher-level page that links to these

[adjourned]