RDF-in-XHTML Task Force

Action Items

<scribe> ACTION: Ben to follow up on media type discussion with Steven, Ralph, and TAG [recorded in http://www.w3.org/2008/03/20-rdfa-minutes.html#action08] [CONTINUES]

<scribe> ACTION: Manu to add test cases for xmlliterals with namespace preservation, including one where the xmlliteral re-declares one of the namespaces [recorded in http://www.w3.org/2008/03/20-rdfa-minutes.html#action09] [DONE]

<scribe> 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]

<scribe> ACTION: Ben to respond to issue 87 [recorded in http://www.w3.org/2008/02/28-rdfa-minutes.html#action09] [CONTINUES]

<scribe> ACTION: Manu to enable EARL output in RDFa Test Harness [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action13] [CONTINUES]

<scribe> ACTION: Manu write a response to Christian Hoertnagl for issue 7 [recorded in http://www.w3.org/2008/02/21-rdfa-minutes.html#action09] [DONE]

<scribe> ACTION: Ben and Ralph to review response to Christian Hoertnagl. [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action07]

<scribe> ACTION: Mark/Shane include issue 89 correction in Changes section [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action11] [CONTINUES]

<scribe> ACTION: Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action12] [CONTINUES]

Ben: we have to review test cases and two issues today.
... Have people read the discussion between TimBL and RDFa TF
... ... concerning DOCTYPE.

Steven: Read it, but not in detail.

Ben: Here's where I think we stand on this...
... ... he's saying if we have a @profile, why don't we just put the equivalent profile in namespace document.
... I'm not opposed to it... we won't put @profile in instance documents and in the namespace document.
... He says that we shouldn't use DOCTYPE
... but the W3C validator won't work if we do that.
... The modularization with schemas isn't REC at the point... so we can't depend on that.

Steven: We could say that when it becomes REC that we will reference it.

Ben: When do we say that?

Steven: We could respond to TimBL and put it in the spec.

Ben: First issue is the idea of putting @profile in namespace document
... Third thing is that RDFa processor shouldn't generate triples outside of default graph.
... Second issue is not using DOCTYPE.

Steven: DOCTYPE declaration is used by browsers currently to switch into standards mode.
... DTDs don't do any harm and people can still validate using them.
... They're still useful.

Ben: Will browsers switch into standards mode using our DOCTYPE declaration?

Steven: Yes.

Ben: Then completely doing away with DOCTYPE is not the correct approach.

Ralph: Do we change a SHOULD to a MAY?
... ... in the syntax document.

<Steven> Without DTDs there are no character entities either

Ben: So we shouldn't force people to do it, but we do think this is a valid way of doing this.

Ralph: Without DOCTYPE we have validation issues.

Mark: We should separate out the different issues here.
... DOCTYPE as per standards mode isn't relevant to us.
... We don't require standards mode and thus it confuses the issue by saying that the reason we have DOCTYPE was because of standards mode.
... If detecting RDFa in the document isn't an issue, then all that matters is validation.
... If we want the document to be validated, they should use DOCTYPE... but that isn't part of the RDFa processing rules.

Ben: I like this direction.
... Then we're saying DOCTYPE becomes a MAY, but we don't require it. You can validate with Schema, but we're providing DOCTYPE because there is no way to validate via Schema right now.

Steven: Sounds good, fine with MAY. We should hear from Shane... he feels strongly about SHOULD.

<scribe> ACTION: Ben to ask Shane about DOCTYPE and validation. [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action10]

Ralph: The second part of TimBL's comment was that @profile should be a SHOULD or not.
... The point there that we might want to consider is that we're really extending the definition of XHTML 1 documents.
... TimBL said that rather than putting @profile in there, we should declare it in the namespace document.

Ben: Are we updating the XHTML namespace document?

Steven: I don't think we need to personally.

Ben: How does this validate with Schema, then?
... How do we validate the additional properties?

Steven: We can update the namespace document...

<Ralph> the namespace document and the schema document are not the same thing

Ben: The namespace document is not the schema document...

Steven: Yes.

Ben: Where is this extra module then?

Steven: The idea is that you validate the document against a Schema..

Ben: How does follow-your-nose fit in here?

Steven: It depends on what you mean... the XHTML2 working group were talking about this.
... if you don't want to put the DOCTYPE in, we can use @version="..."
... That would be what says that the document is XHTML+RDFa.

Ben: If we go down the xhtml namespace route, is there anything that's going to point to RDFa?

Ralph: We're not interested in Schema documents, we're interested in whats at the end of the http://www.w3.org/1999/xhtml URI.
... Tim said that we can add to the namespace document, the declaration that says the interpretation of these RDFa attributes are the following...
... So what does the XHTML2 working group think about that?
... Is modification to the namespace document a process in XHTML2.

Steven: No, we don't feel strongly about that document... documents at the end of namespace URIs are supposed to be informative.

Ralph: TimBL would like that the namespace URI GRDDL to declare a variety of documents at that URI
... One of those would be a machine-readable GRDDL transform that will get RDF out of that document.
... The content of the XHTML namespace document isn't REC and isn't tightly controlled.
... My suggestion, is that in place of the XHTML namespace document, we include in that document that we include enough RDFa to provide the GRDDL transform pointer.

Mark: I'm not sure if TimBL was suggesting one approach over another.
... Ralph seems to be implying that he favors the GRDDL way.

Ralph: He's saying that we should take off SHOULD on the @profile... the only thing you need to put in the XHTML document is your new attributes.
... but that's just one path...

Mark: Got the impression that he's stating that "you're writing attributes, go with it..."
... "for this to be done right, you have now extended XHTML..."

Ben: I agree, to keep folks happy we should do that and we should add a GRDDL flag in the namespace document find it.

Ralph: Where GRDDL comes back in, TimBL isn't pushing GRDDL on us - he's saying that we have the opportunity to modify the namespace document.
... We should do it in a way that understands that there are deployed GRDDL things out there, and we should do something where that stuff just works for us.
... He's not saying we should use GRDDL, but we might as way do it in the way GRDDL suggests.

Mark: Yup.
... The only thing is that there is an issue with circularity.
... if you have an RDFa parser that also supports GRDDL... what happens then?

<ShaneM> is a namespace document the document at the end of a namespace URI?

<Steven> yes

<Ralph> http://www.w3.org/1999/xhtml/

<Ralph> Tim suggests we serve http://www.w3.org/1999/xhtml as GRDDL

Test Cases

Manu: 14 new tests, starting at 88

<Ralph> -- Test #88 (unreviewed): Interpretation of the CURIE "_:"

<msporny> http://rdfa.digitalbazaar.com/rdfa-test-harness/

Mark: the [_:] notation, in Ivan's view, generates a new bnode each time.

Manu: a bit confused

Mark: we haven't decided that.
... this doesn't work in SPARQL, why should it work for us?
... [_:] should act the same way as [_:a]

Shane: nothing in the processing rules to do this.

Mark: well we do use them to generate bnodes

about="[_:bnode1]"

<Ralph> Ben: @about="[_:bnode1]" is a way to refer to a bnode

about="[_:]"

<Ralph> ... the dilemna here is how to interpret @about="[_:]" -- i.e. where there's no local name

<Ralph> ... so Ivan seems to be hoping that [_:] would be a way to instantiate a local name

<Ralph> ... but that's going too far

<Ralph> ... beyond what sparql and turtle do

<scribe> ACTION: Mark to double check the _:a bnode notation in RDFa syntax [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action11]

<ShaneM> I lied - section 6.3.2.4 explains that you can do this. However, nothing in the curie parsing rules NOR in the processing sequence references it.

<Ralph> Ben: maybe we read too much into what Ivan is trying to do

Mark: [Ivan] suggested that there be a shorthand to not having to keep generating local names
... the purpose of this test is to verify that the shorthand does not exist
... the current SPARQL does not match what I think he's requesting

<ShaneM> but I do not understand how you avoid creating a bnode LATER that collides with a bnode that someone put in by hand.

RESOLUTION: test 88 accepted

-- Test #91: Non-reserved, un-prefixed CURIE in @property

Manu: we still generate triples for these

Ben: why the '[:note]' ?

Manu: ah, we don't really need them

Shane: we removed special @property handling

Ben: :next is normal CURIE resolution

Manu: should we add :next to this test case? I think we test it elsewhere

Ben: good to add :next and :foo to show that this is really just normal CURIE resolution, not about reserved words

RESOLUTION: test 91 accepted, with the addition of :foo and removing the '[]' from [:note]

-- Test #92: Tests XMLLiteral content with explicit @datatype

Manu: first of the set of XMLliteral tests
... note the explicit datatype
... the SPARQL is missing xmlns

<msporny> SPARQL should look for: E = mc<sup xmlns="http://www.w3.org/1999/xhtml">2</sup>: The Most Urgent Problem of Our Time

Ben: make sure to correct test 11

Manu: test 11 does not have an explicit datatype
... but does need to be corrected

<markbirbeck> Note that the references to using bnodes in @about, etc., are tucked away in section 6.3.2.4. Although it's a normative section, it should really be drawn out more.

<scribe> ACTION: Manu correct test 11 [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action12]

RESOLUTION: test 92 accepted with fix to add xhtml namespace

-- Test #93: Tests XMLLiteral content with explicit @datatype (user-data-typed literal)

Manu: the effect here is that the example.org namespace is declared and ex:XMLLiteral is _not_ processed as an XMLliteral

RESOLUTION: test 93 accepted

-- Test #94: Tests XMLLiteral content with explicit @datatype (unusual prefix - bla:)

<msporny> SPARQL is incorrect, should be: "E = mc<sup xmlns="http://www.w3.org/1999/xhtml">2</sup>: The Most Urgent Problem of Our Time"

Manu: the author used a non-typical nsprefix for the RDF namespace but it is recognized properly

RESOLUTION: test 94 accepted with correction to XMLliteral to include the XHTML namespace

-- Test #95: No triples with two nested @rel

Ben: this depends on the resolution to the late-binding-of-triples issue
... so we should skip this until we resolve that issue

<markbirbeck> Note to Shane and Manu: "_:p" is also mentioned in section 7.

Manu: same for 96, 97

-- Test #98: Single literal in nested pending triples

Manu: this is a repeat of test 78
... so we should reject

RESOLUTION: test 98 rejected as duplicate

-- Test #99: Preservation of white space in literals

Ben: I thought we'd agreed that all the tests would use normalized whitespace so that parsers who were forced to normalize would be able to cope
... that was my interpretation of the notes made while I was away

Manu: the intent was to not base the spec on the current implementation of MSIE
... we wanted to preserve whitespace but not make that required?

Ben: yes, see resolution ...

<benadida> from 02/14: "RDFa will state that whitespace is preserved and note that some implementations might not behave this way"

Manu: so is it OK to have a test case that some implementations might fail?

Ben: the core issue for me is that this text does not render with the newlines preserved
... so insisting on whitespace preservation breaks the correspondence between what's rendered and what's in the triplestore
... Steven then brought up PRE

Steven: that the newlines are not rendered on the screen is a characteristic of the rendering, not of the content
... the CSS might say to render the newlines
... and the CSS property might change dynamically; you could switch the newlines on and off

Ben: I do know that some HTML authors rely on the fact that they can lay out their source to look pretty and know the rendering will remove the newlines
... I'd be happier if P were PRE

Steven: that's a halfway solution

Ralph: I think PRE might add confusion

Manu: prefer to keep as is

Ben: OK

Manu: not sure if the SPARQL syntax is correct

Ben: we'll find out :)

Mark: SPARQL spec says you can use "\n"

RESOLUTION: test 99 accepted,

Manu: we won't add "\n" until we discover we have to

Mark: the syntax seems to support both real newlines and "\n"

Ben: the remaining tests (100 - 103) are all about XMLLiteral with explicit namespaces

Manu: yes, but there's one issue we haven't discussed; the order of serialization of XML namespaces
... the SPARQL assumes a strict order of serialization

Ben: is this a failure of the SPARQL engine?

Manu: not sure

Ben: per last week's discussion, the SPARQL engine should be doing XML canonicalization
... so if it doesn't match on the triples as expressed, that's a bug in the SPARQL engine

Mark: yeah, that seems right

Ben: it would be nice to write the SPARQL so as to cause the fewest possible failures among the existing SPARQL implementations

Primer

Ben: I'm hoping to show you a highly updated Primer this weekend
... takes into account a lot of comments

<ShaneM> I would like to recomment that you have Roland (XHTML WG Chair) read it. He has had trouble with our Primer in the past.

Ben: I'm happy for continued comments but I'm going to try to hold to a specific new approach that I'm taking

[adjourned]