See also: IRC log, previous 2008-02-28
RESOLUTION: to meet at 1500 UTC from March 13 onward
Manu: do I need to implement something in Crazy Ivan for the EARL stuff?
Ben: let's look for mail from Benjamin Nowack
Manu: I'll speak with Michael
Ben: the Web Service approach to parsing is
only going to work for a subset of the parsers
... e.g. the javascript parsers actually have to run inside the browser
... inherently we'll need multiple ways to run the test suite
Manu: Shane might have been looking into
this
... spidermonkey may help?
Ben: but spidermonkey doesn't do DOM
... so it won't work for Safari, IE, and Opera
Ben: I closed issue 92
ACTION: Ben to respond to issue 87 [recorded in http://www.w3.org/2008/02/28-rdfa-minutes.html#action09] [CONTINUES]
ACTION: [DONE] Ben to update the primer [recorded in http://www.w3.org/2008/02/28-rdfa-minutes.html#action11]
-> latest Primer edits [Ben 2008-03-03]
-> live editor's draft of Primer
ACTION: Mark to reply and process issue 88 [recorded in http://www.w3.org/2008/02/28-rdfa-minutes.html#action10] [DONE]
Mark: I did reply to Johannes but didn't get the formal "OK, I'm happy" response
Ben: I'll take the followup to this action
ACTION: Ben to followup with Johannes on his satisfaction with issue 88 resolution [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action05]
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] [CONTINUES]
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]
Ben: I'll do this after the implementation report is done
ACTION: Ben to email mailing list to think about last substantive issue on tracker: http://www.w3.org/2006/07/SWD/track/issues/6 [recorded in http://www.w3.org/2008/02/07-rdfa-minutes.html#action07] [CONTINUES]
ACTION: Manu write a response to Christian Hoertnagl for issue 7 [recorded in http://www.w3.org/2008/02/21-rdfa-minutes.html#action09] [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]
-> issue 89; confusion regarding completion of hanging triples across intermediate HTML elements
Mark: the problem in the first example (called
"second example") is that when we drop all the way through we fetch the bnode
from the parent
... in the first case this is fine for foaf:name to complete the hanging
triple but it's not fine for the DIV
... it was being handled as if there were no subject, but there's no
_anything_
... Ivan had proposed a solution to this a while ago
... he suggested skipping everything unless one of the significant attributes
were present
... this isn't sufficient, as @lang processing still needs to be done
... Johannes spotted a condition that didn't quite work correctly with the
added skip flag
... the skip flag is _not_ meant to handle superfluous triples
Ben: what changes need to be made?
<benadida> Johannes' mail
Mark: there is a minor error in the skip flag
and an additional error in property
... the property error may not be worth fixing
... when setting the skip flag we should also test that there is no property
value
... 'skip' skips completing the hanging triples (in this case)
... so while it's correct that empty DIV should not complete a hanging
triple, the next foaf:name _should_ complete a hanging triple
... so this correction feels like a minor editorial one to me
Ben: why didn't we discover this earlier?
Mark: it has to do with @property appearing below a hanging triple. Would still be there without the DIV
Ben: we have test cases with @rel and @property below it. Those should complete hanging triples.
Mark: I didn't spot this because in my test
case I have nearly the same markup as in Johannes' example but I added a 3rd
line with an @rel
... unfortunately, my @rel does complete a hanging triple so I didn't spot
this
... this skip flag error only arises if you have only @property
... skip flag is only used at the end of a branch of @rel and @rev
Ben: there's no disagreement in the task force; it seems a small but in the rules
Ralph: let's just document this change clearly in the Changes section
<msporny> Test #33
ACTION: Mark/Shane include issue 89 correction in Changes section [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action11]
<msporny> rdfa-test-harness/
Manu: why didn't we notice this with test 33?
Mark: we now do not complete hanging triples
unless the recursion has given us a reason to complete them
... the box in step "11" (really 10) was not in the previous rules
Ben: is the change a small number of sentences?
Mark: at the very end of step 4, we add "/+and if @property is not present+/ the skip property is set to True"
<benadida> PROPOSE to resolve issue 89 as "update step 4 to take into account @property before setting the skip flag"
<msporny> +1
<Steeeven> +1
RESOLUTION: issue 89 resoved as "update step 4 to take into account @property before setting the skip flag"
ACTION: Mark update editor's draft with issue 89 resolution [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action12]
Ben: the easy issues are mostly resolved in mail
-> issue 97; handing of namespaces and canonicalization of XML literals
Ben: namespaces in XML Literals should be in
the XML namespace
... Mark proposed that the right way to serialize these is to use XML
Exclusive Canonicalization
Mark: Exclusive Canonicalization requires a
root element, called an "apex node"
... we'd be required to do two things:
... 1. dump all of the in-context namespaces onto the apex node
... we have all the in-context prefix mappings in our [evaluation context]
... 2. any embedded namespace declarations are supposed to be removed if they
duplicate declarations on the apex node
... I think we can drop this step
... I've talked with Ivan about this and he thinks he might be able to
implement it
... but if there's no apex node I don't think we can do anything
... Exclusive Canonicalization does not _require_ the implementation to
create an apex node; it mostly does not deal with things that don't have apex
nodes
... RDF Concepts document only requires that an XMLLiteral be a well-formed
thing; e.g. it can be inserted as a child of some other element and the
result is well-formed
Ben: how much of a problem would it be for us to say that namespaces must be specified [within the literal] if the author wants them
Mark: RDF Concepts says XMLliterals must
conform to Exclusive Canonicalization
... so I think our loophole here is in the Exclusive Canonicalization
specification
Ben: I don't want to have to do XML [namespace] processing in the parser
Mark: we could drop XMLLiterals alltogether and
reserve the datatype, saying it's for a future version
... we could wait and see how implementations experiment with the idea
... alternatively, continue processing as now but once the parser encounters
an XMLLiteral treat it as a string rather than do XML processing
... create a string representation of the XML
Manu: I'm hesitant to require processing all
the XML
... adds a lot of complexity to the parser
... I'd prefer to take the inner text as-is and not require processing of
it
<Steeeven> +1
Manu: or leave the question to a future spec
Mark: I have lots of use cases for XMLLiterals but I'm also not inclined to require processing the inner text
Steven: keep the inner text as-is with the markup
Manu: I do think people will have requirements to preserve all the inner markup
Mark: taking the inner text is really useful
for the 80% case, particularly for round-tripping uses
... the problem is that calling the result an RDF XMLLiteral then it has to
actually be one, and Exclusive Canonicalization is then required
... could we call it an "RDFa XML literal"?
Manu: rdfa:literal?
Ben: I'd prefer to look for a different solution and avoid rdfa:literal ; we're not supposed to be adding RDF features
Ralph: +1 to Ben
<msporny> rdfs:Literal ?
Ben: I see 3 solutions; 1. resolve exclusive
canonicalization, which seems to require XML understanding in the parser
... 2. find another datatype that allows us to preserve the markup but
doesn't require exclusive canonicalization
... 3. leave it undefined in this version
<msporny> I would prefer option #2: find another datatype that allows us to preserve the markup.
Mark: in (3), I'd still suggest a paragraph that makes suggestions; e.g. "just take the inner string with the markup which isn't precisely an rdf:XMLLiteral but it's close enough for many users"
Ben: let's post a summary to the mailing list and solicit feedback
<msporny> http://www.w3.org/TR/rdf-schema/#ch_literal
Manu: perhaps rdfs:Literal gives us enough leeway
Ralph: I'm pretty sure rdfs:Literal will not do
what we want
... but let's put it to the list. Some of the RDF Core WG participants may
have useful advice
ACTION: Mark to summarize issue 97 and 3 options for XMLLiteral to mailing list [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action13]
Ben: please do look at the Primer [editor's draft]
... and send comments
... should we push out an updated Primer quickly and then do another WD in a
few weeks or wait?
Ralph: how confusing is the current WD?
Ben: the changes are mostly in @src
... perhaps the WGs can review these changes quickly
Ralph: I'm in favor of doing a quick update to
resync followed in a few weeks by another update
... but the risk in doing a rush update is in overlooking something else
that's out of sync that might then create more confusion
Ben: I'll try to write a diff document later today
[adjourned]