RDFa Task Force

ACTION: Ben enter Ivan's concerns in http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Oct/0173.html as issues in tracker [recorded in http://www.w3.org/2007/10/18-rdfa-minutes.html#action08] [CONTINUES]

ACTION: Michael and Manu investigate with Ivan the implementation of the test case validator proposal on w3.org [recorded in http://www.w3.org/2007/10/18-rdfa-minutes.html#action07] [IN PROGRESS]

Manu: test harness and validator pretty much done
... only item left to talk with Ivan about is where to host

ACTION: Ben to add status of various implementations on rdfa.info [recorded in http://www.w3.org/2007/10/04-rdfa-minutes.html#action06] [CONTINUES]

ACTION: Ben to set up a proper scribe schedule [recorded in http://www.w3.org/2007/10/11-rdfa-minutes.html#action01] [CONTINUES]

ACTION: Michael to create "Microformats done right -- unambiguous taxonomies via RDF" on the wiki [recorded in http://www.w3.org/2007/08/23-rdfa-minutes.html#action06] [CONTINUES]

Ralph: I was asked to join a SWEO face-to-face on Wednesday to talk about RDFa outreach
... I pointed out that Michael has this action

Manu: I'm heavily involved in microformat community
... I could talk with SWEO

-> SWEO WG

Ben: There were some recent responses on the mailing list too, offering help

Ralph: Syntax doc was published last Friday
... SWD approved publishing new Primer on Tuesday
... Ben has given me the PubRules-compliant version of the Primer today, so I hope to be able to finish that this afternoon

Status of Test Cases / Test Harness

<msporny> http://rdfa.digitalbazaar.com:8080/

Manu: anyone who has implemented their RDFa parser as a on-line Web service can use this harness
... Benjee has started to use it
... two of the test cases have not been updated
... tests 11 and 29 fail
... they shouldn't fail

Mark: this is about stripping whitespace

Manu: yes; they pyrdf implementation differs from Benjee's

Mark: I thought we had concluded that we should strip whitespace [from the test cases]
... because some browsers always strip whitespace, so it can't be recovered

Ben: yes, we'd agreed to strip whitespace
... we added a pointer to the CSS language

Shane: Steven is the right person to describe this language
... I wanted to defer to CSS language
... the issue the XHTML2 WG faced was that we were asked by CSS not to reproduce their text so as not to introduce errors
... we then copied their text verbatim but they didn't like that either

Manu: so should we just point to CSS?

Mark: no, we don't want our spec to change as a result of CSS changes
... we might even want to adapt the language to our processing model

Shane: it's identified as an issue in the draft

Ben: I'll talk with Michael about test 29; that's part of my action to turn Ivan's comments into issues

Manu: are we also stripping whitespace from XML literals?

Mark: yes, I think we have the same problem there and need to be conservative
... that does mean we might lose information, e.g., in PRE

Ben: there are rules that browsers follow to preserve whitespace in PRE
... are those documented anywhere?

Mark: part of the problem is that the HTML and XHTML rules are different

Shane: maybe. I've heard people say this, but never heard a CSS expert say so

Mark: I thought we needed certain CSS rules because HTML does remove leading and trailing spaces
... but I didn't encounter this problem in an HTML DOM

Ben: I have experienced this problem
... in FireFox, the DOM has stripped the whitespace
... when writing HTML I like to space things out; the browsers seem to ignore this

Mark: we can define processing of literals differently from XML literals
... it would be nice to find out from implementors those cases where whitespace is stripped

<Steven> I'm willing to take a look

<Ralph> at adapting the CSS language, Steven?

<Steven> yes

<Ralph> great; thanks

ACTION: Steven propose an adaptation of the CSS whitespace rules to incorporate into the Syntax document [recorded in http://www.w3.org/2007/10/26-rdfa-minutes.html#action06]

Mark: let's try to resolve the issue on whitespace in literals on the list

Ben: I do see FireFox stripping the whitespace and I like it that way

Mark: I'll double-check mine, then; I'm pretty sure I'm seeing whitespace preserved

@instanceof

Mark: Ben and I had a long conversation and we have agreed on an approach to resolve the issue
... Ben has sent me a set of use cases and I'll look at them

handling @rel legacy values

Mark: not only the HTML rel values but also other uses, e.g. Dublin Core

Manu: some of the proposed triples seemed strange in relation to Mark's proposal

Shane: none of my triples addressed Mark's proposal
... (with my XHTML hat ...)
... in the XHTML world there are some defined values in XHTML 1, XHTML 1.1
... this is an extensible set
... the purpose of adding RDFa to XHTML2 two years ago was to help enable the Semantic Web for the common use cases
... that's why the XHTML2 WG is interested in RDFa
... so requiring the defined values to include a ':' does not address the XHTML2 use case

Ben: there's also forward-looking interest from XHTML2

Shane: yes, on extensibility
... but the initial goal was to take advantage of the community mindshare that existing markup does generate triples

Mark: I do favor Shane's position, however given the problems we've had in that discussion, I've given up on pursuing that
... so I'm suggesting a solution that doesn't skew things so we're prevented from doing other things in the future
... so adding ':' prefix is a sort of minimal solution
... if we take it informally that people should also parse 'next' and 'prev' in addition to ':next' and ':prev' but not specify how, that will buy us some time
... we should take our time to get this right; look at Dublin Core, @profile, and others

Manu: I agree with Mark
... the biggest problem we've had in talking with microformats is in defining how these things should work
... moving the discussion into legacy versus here's what you get by adding RDFa is a way to move forward, without discussing specifically what properties come from [specific values of] @rel and @rev
... could we get feedback from the XHTML2 WG?

Shane: I don't think we'd get a different answer from the XHTML2 WG than the ones Mark and I just gave
... there's value in saying the author has to explicitly say they want a triple [by adding ':']
... but it's not consistent to say that implementations may generate other triples and allow those triples to appear in the default graph

Mark: it's a matter of interpretation whether @rel='next' exists yet as a triple
... I have strong views on the solution, so the discussion may take a while

Ben: we're defining RDFa. @rel='next' already has a meaning based on the XHTML1.1 specification
... the idea behind Mark's proposal is "don't mess with the existing meaning"
... so Mark's proposal is that RDFa not change the meaning
... since there is a meaning

Ralph: but the current meaning is not expressed as a triple, so the RDFa spec should not encourage generating that triple without defining it

Mark: My proposal is to not specify a triple for @rel='next'

Shane: would we change CURIE to require ':'?

Mark: no

Shane: so the processing rules would change to ignore when there's no ':'?

Ben: those sound like flimsy host-language-specific rules

Mark: I'm suggesting 'undefined' rather than 'not processed'

Manu: with the notion of a preprocessing step, 'ignore anything without a colon' works
... later, preprocessing can add ':' to @rel='next'

Mark: I'm trying to avoid saying anything about preprocessing

Manu: we do expect to define preprocessing in the future

Mark: yes, but we don't yet know enough about what we want to specify in preprocessing
... we don't currently know enough to specify how to deal with the legacy values
... I don't see a big issue in citing examples of legacy values and saying "we don't know yet how we want to handle these"

Shane: I think if we're not going to solve this in the first Recommendation for XHTML1.1+RDFa, then we don't need to ever define it
... once we've established a baseline that requires a ':', we should just stick with it
... this is separate from whether CURIEs must have a colon
... just triples require a colon

Ralph: my concern is about interoperability
... we're not doing the community any favors if we release a spec that we *expect* will be implemented different ways without interoperability

Schedule

<Steven> http://www.w3.org/2006/07/SWD/wiki/RDFa#RDFa_schedule

Ben: we'll need to push to resolve these issues before [Nov 22], as things will slow down after then

Shane: will we meet on 8 Nov?

Ben: no
... but 1 Nov we should meet; note it will be 1 hour earlier for Europeans
... i.e. at 1500 UTC
... after November it will be at 1600 UTC

[adjourned]