Mark: HTML WG was able to wrap up all its open issues at its most recent face-to-face
<jeremy> implementation notes
Jeremy:I revised the rules from the old implementation and wrote code for CURIEs. This has some minimal testing. The rules are simpler and there is significantly less interaction between the rules. The current RDF/A spec describes rules more precedurally.
<jeremy> Rules file in implementation
<jeremy> <subject
<jeremy> rdf:about='my:resolve-uri-curie(ancestor::*[@about][1]/@about,ancestor::*[@about][1])'
<jeremy> rdf:nodeID='my:bnode-uri-curie(ancestor::*[@about][1]/@about)'
<jeremy> x:para='4.3.2'
<jeremy> a:match='[not(self::xhtml2:meta)][not(self::xhtml2:link)][not(@about)][ancestor::*[@about]]'
<jeremy> />
Mark: from the viewpoint of an HTML DOM, I had a mental model with a document containing lots of notes and <meta> and <link> get 'absorbed' into their parent
Ralph: the xml:base from ancestor containing about= probably warrants a test case -- I expect it will be a not uncommon bug
Ben: the about= should be resolved at the point it is expressed, not later when it is used
Mark: did you find the fit with xml:base and CURIEs to be easy to implement?
Jeremy: I tried to write a flexible implementation; I break the CURIE into prefix,localpart using some variables. Prefix resolution is currently done by namespace lookup but that's a module. I did not find any particular problems implementing CURIEs
<jeremy> http://www.w3.org/2001/sw/BestPractices/HTML/implementation/base.xsl
<jeremy> has the CURIE-URI
Jeremy: regarding <head about='...'> edge case, I don't have a particular preference but it's wrong to leave it unspecified; the reification of a <meta rel=... rev=...> needs to be specified -- this is a corner case of multiple triples with the same reification id
<jeremy> <meta id="r" property="foo" rel="bar"><meta .....
(or use <link> in place of outer <meta>)
<jeremy> <#r> rdf:predicate <foo>. <#r> rdf:predicate <bar>
Mark: meta and link are now special; perhaps they should not permit rel and rev
Ben: we did not address in the spec the case of <meta id...> or <link id...>
<jeremy> <meta property="foo" rel="bar"><meta .....
<jeremy> _:a rdf:predicate <foo>. _: b rdf:predicate <bar>
Jeremy: without an id attribute you construct two distinct bnodes
<jeremy> <meta property="foo" rel="bar"><meta property="dc:creater" content="MB"/>
<jeremy> _:a rdf:predicate <foo>. _: b rdf:predicate <bar> . _:a dc:creator "MB". _:b dc:creator "MB" .
Jeremy: the inner <meta> makes the same assertion about both triples (property and rel) in the parent <meta>
Mark: given <span ...><meta> ...
Jeremy: in that case the meta would be about the span, not about the triples because meta and link are special in referring to their immediate parent. This is useful functionality though it is more implementation work. I am not sure the additional compactness of reification is worth adding to the implementation cost
Mark: if there is uncertainty about future consensus on reification, then whatever we specify now might become outdated
Jeremy: the Last Call document could specifically request feedback pro and con on the proposed specification
Ben: my approach was to express [as much as possible of] RDF and not make a judgement about goodness or badness of features
<jeremy> <meta id="r" property="foo" rel="bar"><meta .....
<jeremy> perhaps makes the triples
<jeremy> _:a rdf:predicate <foo>. _: b rdf:predicate <bar> .
<jeremy> and loses the #r
<Ralph> [it feels odd to me to be discarding the id in this example]
Ben: add this to the issues list?
Jeremey: it's really just a corner case in which the spec doesn't adequately say what to produce
ACTION: Jeremy followup with Mark on the question of multiple triples from nested meta and add to issues list
ACTION: Jeremy propose wording on reification
Jeremy: the question is not whether RDF/A supports reification -- it will -- but rather whether there is a compact representation for reification
ACTION: Jeremy followup on <head about=...> edge case
ACTION: Ben start separate mail threads on remaining discussion topics
Ralph: have we formally asked the WG for a consensus on the CURIE proposal?
Jeremy: I am willing to put that question to the WG
Ralph: perhaps proposing to publish the CURIE spec as a Working Draft would be a way to call this question. I may have to either abstain from that vote or represent that the Team does not have consensus
next meeting: 13 Dec
[adjourned]