See also: IRC log
<msporny> Scribe: Manu_Sporny
<msporny> scribenick: msporny
Previous: http://www.w3.org/2009/09/10-rdfa-minutes.html
<benadida> manu: yes, call at 12pm eastern on HTML and RDFa FPWD
manu: I'll be on that call
<scribe> ACTION: Ben to put up JS code that implements the xmlns algorithm on "RDFa Implementors' Guide" wiki [recorded in http://www.w3.org/2009/09/10-rdfa-minutes.html#action07] [DONE]
<benadida> --> http://rdfa.info/wiki/Rdfa-implementors-guide#JavaScript
ben: it will work in HTML5, but not XHTML5
<benadida> ACTION: Ben to update JS xmlns getter code on implementors' guide for xhtml mime type support [recorded in http://www.w3.org/2009/09/17-rdfa-minutes.html#action02]
<scribe> ACTION: Ben to send Philip a "consensus of the task force" email that there is an issue, but not RDFa's. [recorded in http://www.w3.org/2009/09/10-rdfa-minutes.html#action06] [DONE]
ben: The issue may not be done.
... This is about XMLLiteral c14n -- is it RDFa's job or the SPARQL processors
job?
ivan: Let's try to close this issue.
... SPARQL spec doesn't say that it does c14n
... what this boils down to is that the Test Cases, the SPARQL code that we
use should have the canonicalized XML in it.
... the test cases are more liberal than they should be when it comes to
c14n
manu: I don't know if the spec is correct.
ivan: Canonical XML states that we should insert the namespaces that are used in the literal, and nothing more.
manu: We might give a different impression to implementers
ivan: We might want to clarify things as well in a future editors spec.
<scribe> ACTION: Manu to review test cases on default namespace preservation [recorded in http://www.w3.org/2009/09/10-rdfa-minutes.html#action04] [DONE]
<benadida> --> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0158.html
manu: The test case issues are outlined in that
e-mail
... the other issue is the c14n vs. proper XMLLiteral RDFa preservation.
ben: Yes, there is an issue here and the issue is slightly larger than RDFa.
ivan: The SPARQL group are considering an
official errata for RDF to address this issue.
... This is an issue that came about years ago, but we need to deal with
it.
ben: So, what is the path forward.
<benadida> http://rdfa.info/wiki/Rdfa-wg-charter
manu: Accept c14n XMLLiteral definition and accept that we won't be able to preserve namespaces for RDFa in XMLLiterals
<scribe> ACTION: Ben to create RDFa WG charter template. [recorded in http://www.w3.org/2009/08/20-rdfa-minutes.html#action04] [DONE]
ivan: Let's put the charter off for 6-8 weeks. We're not under huge pressure to do that.
ben: I don't think we should submit the charter now, but we shouldn't delay it.
<Zakim> ShaneM, you wanted to discuss schedule
shane: I'm the one who pushed schedule because these things take time.
ivan: If we do this in November, this shouldn't be an issue.
<benadida> msporny: sam ruby and doug schepers have offered to host an RDFa TF in HTML and SVG WGs.
<benadida> ben: I'm not convinced that this is a good idea yet.
ivan: A Task Force between two working groups
work well when two groups are friendly with each other.
... It's also more administration overhead.
... I'd prefer the RDFa Core work to stay in SWD.
<markbirbeck> Should also add that it works when the two groups are complementary to each other.
ivan: There are things that we may plan to do that have nothing to do with HTML.
<markbirbeck> Which is not the case here.
ben: One thing we should try to steer clear of
anything that doesn't follow W3C process.
... We should be collaborating with HTML WG.
... We should strive to be true to W3C process.
ivan: Let's wait and see how the HTML+RDFa FPWD works out. If it works, then that would be best.
ben: We depend on rel with a bad value and the
absence of rel as being different.
... We do not do the same for @typeof.
Ivan can you scribe?
I can clean up the minutes afterwards
<ivan> scribenick: ivan
mark: when I made all the changes to cleanup curie processing, then I might have missed this
shane: wait...
mark: I think the discussion on the list is pretty good
shane: ben said rel="" and rel="rubbish" is not the same thing
mark: if I completely remove rel from an element,
then there is no hanging stuff kick in
... if there is a rel, then the mechanism does kick in
shane: the real issue is with datatypes
... and with typeof
... typeof does not have a special behaviour for typeof=""
mark: the issue does originate from the datatype
handling
... during the course of discussion I discovered that typeof does not behave
like we meant it
... there are two issues: (1) datatypes and (2) typeof
shane: our intent is clear
... and all implementations that passed the tests did it like we intended
... we can put the two phrases into the places where it needs it then we are
done
manu: do we feel that we have a clear text that
we can put in? Did we check that against the test cases?
... there might have to add some new test cases
... i do not know what my parser would do...
mark: the key thing is that it creates a b node
shane: the final piece here is where jeni is
incorrect
... if there is typeof, it generates a bnode, but that one is not used as a
subject of another triple
mark: but it can complete hanging triples
<ShaneM> Jeni says in an email:
<ShaneM> In the case of
<ShaneM> <p xmlns:ex="http://example.org/" about="http://example.com/" rel="ex:rel3">
<ShaneM> <span property="bogus:bogus" content="Content 3">
<ShaneM> <span about="http://example.net/">Test 3</span>
<ShaneM> </span>
<ShaneM> </p>
<ShaneM> by the same argument, we should create:
<ShaneM> Default graph:
<ShaneM> <http://example.com/> <http://example.org/rel3> _:a .
<ShaneM> Graph A:
<ShaneM> _:a bogus:bogus "Content 3" .
mark: the key thing is to preserve the structure, the hierarchy, even if the gaps are not filled in
shane: what I pasted in is the bit where she is wrong
mark: I will double check that
... the mere presence the property will complete the hanging triple
... so what she says is correct
shane: I think that the spec says explicitly that the bnode should be used only if it is used down the line
mark: the spec says that graph A may be generated
but it is not required
... the question is whether the first triple should be generated
... ie whether the hanging triple should be completed
shane: I do not feel this is what the spec says
mark: but there may be a mistake; the whole point
of the default graph idea is to make such issues valid
... maybe people can have a read of the spec, I think that triple should be
generated
... very end of step 4 with the skip element flag
... and that is reused at point 10
... maybe people should look at it with their own implementation
manu: meeting adjurned