RDFa Task Force

ISWC

Michael: lots of questions, especially "when will the spec be finished?!"
... lots of discussion of open data
... see Ivan's blog

Michael: I talked with Fabien for a while, especially about profile
... Fabien said he'd be happy to give his stuff to W3C
... we already have the RDFa GRDDL profile URI assigned

Ben: is there a licensing question for Fabien's work?

Michael: not aware of one

ACTION: Ben followup with Fabien on getting his RDFa GRDDL transform transferred to W3C [recorded in http://www.w3.org/2007/11/15-rdfa-minutes.html#action01]

Michael: there were two RDFa-based things shown at ISWC
... most people seemed to already know about RDFa

Action Review

ACTION: [WITHDRAWN] 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]

Ben: given consensus forming around Mark's proposal on the mailing list I think we can withdraw this

ACTION: [DONE] 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]

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 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] [DONE]

Manu: it's hosted outside of W3C right now
... we'll wait until we've published a public draft before moving it to W3C
... easier to fix bugs on my site before moving it to W3C

Ralph: would a proxy URI work given your implementation?

Manu: not sure; there's a lot of javascript
... there's a redirect right now
... I'll find the URI after this call

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]

follow-your-nose

Ralph: have we decided this?

Ben: yes, we've agreed that @profile is permitted but not required

Ralph: have we documented this adequately?

Mark: no, I've not finished the words in the syntax doc

Michael: Shane suggested a way to anchor the syntax doc so it can be referenced from the test suite

-> issue 28 follow-your-nose

"2007-11-15: agreement from telecon that we have a profile, we encourage its use where possible, but we don't require it. This needs to be stated clearly in the syntax (it's not currently.)"

whitespace canonicalization

-> [Fwd: ISSUE-63: White-Space Canonicalization of XML Literals] [Ben 2007-11-08]

Ben: I think we agreed to use XPath normalized space rules
... to canonicalize non-XML literals
... 3 pieces: plain literals - no data type declared or datatype declared as empty
... for plain literals, use XPath normalized space as Mark proposed

Michael: Fabien would like us to base on XPath too

Ben: any objections?

(none)

Ben: PROPOSE plain literals normalized using XPath normalized space

<mhausenblas> +1

RESOLVED plain literals are normalized using XPath normalized-space

Michael: technically this means remove leading and trailing whitespace and collapse consecutive whitespace to a single whitespace

Ben: parts 2 & 3 - typed non-XML literals and XMLLiterals
... for non-XML literals I believe we should do the same thing [as plain literal]

Manu: are there any XSD datatypes that require spaces?
... if not, the argument in favor of using XPath normalized-space for this too is stronger

Ben: I'm not aware of any; they'd be hard to render in HTML
... what do we do with value of @content ?

Mark: I'm drafting a reply to the mail
... I'm not sure what we should do with all the cases
... the more I've looked into this, the more awkward it seems to be getting
... mainly the relationship to the browser
... the normal behaviour with XML appears to be to remove white space even in an attribute

Manu: no, xs:normalize-string tells the XML process to remove whitespace and the default is to preserve whitespace

Ben: let's close the non-XML cases first

<benadida> <span content=" foo bar " />

Ben: are spaces in @content preserved? I suspect so, but am not sure

Mark: we're limited in our flexibility because of what browsers actually do
... if there are browsers that return "foo bar" in that example, or browsers that remove newlines, we'd have to force normalization

Ben: it's clear to me that we want to normalize whatever the user would actually see
... not so clear what should happen for @content

Mark: the rendering of content with whitespace is already clearly defined
... consecutive whitespace is collapsed

<mhausenblas> Support Mark: -> XML spec

Mark: question is what the DOM level returns in a query

Ben: I think element content and attribute values are handled differently by browsers
... e.g. Firefox appears to preserve all whitespace in attribute value
... seems to support the model that data visible to user is normalized and when the author wants to override that, use @content

Mark: seems that could work

Manu: sounds like a good approach

<mhausenblas> XHTML spec

ACTION: Ben check that browsers do preserve whitespace in attribute values [recorded in http://www.w3.org/2007/11/15-rdfa-minutes.html#action07]

ACTION: Michael check that HTML spec says to preserve whitespace in attribute values [recorded in http://www.w3.org/2007/11/15-rdfa-minutes.html#action08]

Ben: assuming that element content is normalized and attribute values preserve whitespace,

<benadida> normalize: <span property="dc:date" datatype="xsd:date"> 2007-11-15 </span>

<benadida> don't normalize: <span property="dc:date" datatype="xsd:date" content=" 2007-11-15 " />

Ben: does it make sense to normalize element content and not normalize @content even when datatype is specified?

Manu: yep, makes sense

Mark: in XML spec, there's full normalization of element content; newlines removed, whitespace collapsed
... then there's another kind of normalization that replaces newlines with a single whitespace
... if there were a newline in @content, that would have become a single space

<markbirbeck> http://www.w3.org/TR/2000/REC-xml-20001006#AVNormalize

Mark: so it's not just leaving attribute value untouched

Ben: Firefox appears to remove newline from attribute value

<markbirbeck> http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_user_agent

Ben: on further testing, Firefox strips leading newline but preserves non-leading newlines
... so we need to both understand the [XML] spec and investigate what browsers are actually doing
... hopefully the browsers are doing something sensible

Michael: and hopefully the browsers behave consistently

Mark: we could add our own rules, such as requiring leading newlines to be stripped

Ben: for XMLLiterals, I'd like us to preserve them if we can
... but if browsers do canonicalize, I think we have to allow it
... I don't expect canonicalization to change how the literal is rendered
... conclusion; we'll normalize plain literals and element content but not normalize @content value except perhaps for special rule about leading newlines depending on what browsers do
... I need to test both in HTML and XHTML mode

@instanceof

-> chaining-friendly rules for @instanceof [Ben 2007-11-08]

Mark: happy with the list discussion
... I'm more clear now on where the problems lie
... in most areas Ben's proposal and mine appear to be in agreement
... my main problem with Ben's @instanceof rule is that things change meaning as you add or remove markup
... I feel strongly enough about the flipping of meaning that I'd rather remove @instanceof for now in the interest of time
... reinvention of chaining shows it is a useful concept
... I think we can tweak things to work
... and easier than trying to make @instanceof sometimes apply to subject and sometimes to object
... I'd like to say that adding predicates always behaves consistently
... once a subject is declared, predicates are added to it in a consistent way
... people need time to look through the long emails

Ben: does this really only concern @instanceof? in email Mark described chaining rules that appear to interpret some markup differently

Mark: I couldn't see any differences in the treatment of chaining if we drop @instanceof except one case where I have an additional rule
... the general idea of chaining is that there's a subject and predicate and the object can become the subject of further predicates

<benadida> <div rel="foaf:knows"> <span about="#ivan" property="foaf:name">Ivan</span> </div>

Mark: the one rule I've added is @rel without an object can take object from @about in a child element

Ben: in my example above, I believe the current parsing rules do not cause chaining
... in Mark's proposal this example would cause chaining

Mark: right.

Ben: if we accept this model of chaining but keep @instanceof, then are there use cases we can't express?

Mark: I don't think so

Ben: I think that having an element pick up the object from a child is core to solving some use cases

<markbirbeck> <div rel="foaf:knows"> <span property="foaf:name">Ivan</span> </div>

<benadida> <> foaf:knows [foaf:name "Ivan"] .

Mark: in my model, @instanceof behaves no differently from any other predicate

<markbirbeck> <div rel="foaf:knows"> <span property="foaf:name" instanceof="foaf:Person">Ivan</span> </div>

Ben: the way I interpret Manu's rules, it seems there is no chaining

<markbirbeck> <> foaf:knows [foaf:name "Ivan"; rdf:type foaf:Person] .

Ben: the foaf:knows would be left hanging

Manu: that's not what I meant
... I meant what I think Mark is proposing
... I don't think there's a difference between what Mark is saying and what I was trying to say

Ben: I'm worried about some inconsistencies

Ben: Other issues?

(none)

Ben: Will send out some examples - TF members will play mechanical-turk-parser

<markbirbeck> http://newsbiscuit.com/article/disillusioned-mr-google-resigns-199

<markbirbeck> On being a mechanical turk :)

<msporny> :)

Michael: Regarding TC we need to get the one which are on-hold either approved or get rid of it

Ben: We are on good way to Last Call - let's keep on the good work!