Contents

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

Issue-89

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

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

Easy Issues

Issue-97

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"

Primer

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