See also: IRC log, previous 2008-04-24
<danbri> may I join?
<danbri> trying to catchup on state of RDFa. Promise to listen/learn quietly...
Ben: regarding issue 103, last week's discussion about issue 116 seemed to touch on this
ACTION: [DONE] Manu to reply PFWG regarding ISSUE-114 [recorded in http://www.w3.org/2008/04/24-rdfa-minutes.html#action11]
ACTION: [DONE] Michael to add a section to Wiki regarding ISSUE-114 [recorded in http://www.w3.org/2008/04/24-rdfa-minutes.html#action12]
ACTION: [DONE] Michael to reply to Elias and Lee regarding ISSUE-11 [recorded in http://www.w3.org/2008/04/24-rdfa-minutes.html#action13]
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]
Ben: I talked with Fabien and Ivan in Beijing. No obstacles yet.
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] [WITHDRAWN]
Shane: I believe this action should be
closed
... the XHTML WG has already responded to the TAG
... the XHTML2 WG resolved this 3 months ago
Ben: I did chat with Tim in Beijing and he fully supports updating the XHTML1 namespace document
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 respond to ISSUE-109 with (if possible) pointers to past discussion of @cite [recorded in http://www.w3.org/2008/04/17-rdfa-minutes.html#action12]
<benadida> my response
ACTION: Manu to enable EARL output in RDFa Test Harness [recorded in http://www.w3.org/2008/03/13-rdfa-minutes.html#action13] [CONTINUES]
ACTION: Mark to move _:a bnode notation to normative section [recorded in http://www.w3.org/2008/04/03-rdfa-minutes.html#action05] [CONTINUES]
ACTION: Mark/Shane include issue 89 correction in Changes section [recorded in http://www.w3.org/2008/03/06-rdfa-minutes.html#action11] [DONE]
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]
ACTION: Ralph to review response to Christian Hoertnagl. [recorded in http://www.w3.org/2008/03/27-rdfa-minutes.html#action07] [WITHDRAWN]
<benadida>implementation-report
<danbri> (i wonder if 2008.xtech.org/public/schedule/detail/528 is an implementation report; if implementors include publishers, and not only parser-writers)
Shane: remember, we don't need the implementation report to _start_ CR
Ralph: yes, but we're hoping for a short CR so let's not let it slip
Manu: does every implementation have to pass every test?
Ralph: no, but every feature should be
implemented by at least two
... and ideally there will be at least two implementations that do pass
everything
Ben: we can include every implementation in the
report unless we lose touch with a developer and can't get responses to a
test failure
... I do think there should be at least one javascript implementation in the
report
... Elias is working on a javascript API for the test harness
Ben: status of tests?
Manu: there are only two pending; let's defer this to next telecon
Manu: I'm not aware of any new tests entering the pipeline
Mark: change made in Shane's CVS repository, will be in the next editors' draft he publishes
<benadida> issue 113
Manu: the resolution boiled down to "we don't
specify this"
... Shane pointed out that the meaning of a fragment may change entirely when
put into another document
Ben: it's possible to write a chunk of XHTML+RDFa that will preserve its meaning across documents
Shane: I disagree; in the context of this document we have no formal definition of the behaviour
Ben: in Creative Commons use case we specify a fragment that means what the author _intends_ it to mean when pasted into any document
<danbri> (blogged/syndicated markup is another common scenario)
Ralph: but the subject of the triple changes
Ben: yes, that's why I said "intended to
mean"
... in the Use Case document we do talk about fragments, e.g. of widgets
... how should we acknowledge this?
Manu: in the wiki perhaps?
Mark: at the top of the processing rules
section there's something that talks about _usually_ starting at the root
... we could make this explicit
Ralph: I disagree that we should specify the interpretation of a parsed fragment
Mark: it's very easy to say "here is the
context, begin parsing"
... not saying we need to spell out how to do it
... just that it's possible to answer Micah's point
Ben: I'll try to craft a short non-normative paragraph
<danbri> (NOTE-webarch-extlang#Local articulates something like this requirement)
Mark: the searchmonkey documentation mentions
"dataRSS"
... in there you'll find @resource and a statement that "this is RDFa inside
dataRSS"
... I hope Ben's paragraph will be sympathetic to this
<msporny> +1 to draft small paragraph
ACTION: Ben draft a non-normative paragraph on RDFa fragments for review [recorded in http://www.w3.org/2008/05/01-rdfa-minutes.html#action13]
Ralph: but issue 113 asks for processing rules that apply when there is no <head> nor <body> and we're _not_ going to do that
Mark: Micah also asks that we "mention the
possibility"
... we can mention the possibility without describing normative behaviour
Ben: PFWG's concern is that any markup in the element content is lost when @content is added
<benadida> my response
<benadida> "I like the idea of emphasizing this point, that @content should be used
<benadida> as a "last resort," and we'll discuss it in the group."
Ralph: the point of @content was to override
element content when it's necessary to do so
... if the author mis-uses this, then, well ...
Ben: but should we change anything in the spec?
Mark: we have discussed having multiple
versions; could have two objects
... we don't have this multiple value approach anywhere else and shouldn't
have it here
<ShaneM> "Note that the use of @content prohibits the inclusion of rich markup in your content. It is a tool of last resort. If the inline content of an element is meaningful, then documents should rely upon that rather than duplicating that content using the @content attribute."
Mark: this feature also allows a distinction between XMLLiteral and plain literal
<msporny> +1 for Shane's wording...
Shane: I think we could put guidance such as the above in the document
Mark: I object to "tool of last resort". There are use cases where the thing you want in the human-readable part is different from what you want in the machine-readable part
Ben: the point is that if the value
can be rendered on screen, then don't use @content
... Bob Ducharme used to show examples where everything in the HEAD was
hidden on-screen and I think we want to discourage this practice
<ShaneM> "Note that the use of @content prohibits the inclusion of rich markup in your content. If the inline content of an element is what you are trying to convey, then documents should rely upon that rather than duplicating that content using the @content attribute."
Ralph: I'd be satisfied with Shane's paragraph with the "tool of last resort" sentence dropped.
<markbirbeck> oops...just remembered that Steven asked me to give his apologies!
<markbirbeck> Very sorry... :)
<benadida> PROPOSE to resolve ISSUE-115 by adding a short non-normative paragraph approximately as follows "Note that the use of @content prohibits the inclusion of rich markup in your content. If the inline content of an element is what you are trying to convey, then documents should rely upon that rather than duplicating that content using the @content attribute."
<Ralph:> +1
<msporny> +1
<markbirbeck> +1
RESOLUTION: ISSUE-115 closed by adding a short non-normative paragraph approximately as follows "Note that the use of @content prohibits the inclusion of rich markup in your content. If the inline content of an element is what you are trying to convey, then documents should rely upon that rather than duplicating that content using the @content attribute."
ACTION: Shane update editors' draft with the resolution to issue 115 [recorded in http://www.w3.org/2008/05/01-rdfa-minutes.html#action14]
ACTION: Ben respond to the commenters on issue 115 [recorded in http://www.w3.org/2008/05/01-rdfa-minutes.html#action15]
<benadida> issue 104
PROPOSE propose to copy the datatype definition from WD-curie-20080402/#s_schema
<msporny> +1
RESOLUTION: Copy the CURIE datatype definition from WD-curie-20080402/#s_schema
Shane: the XHTML2 WG had a comment that the correct name is URIorSafeCURIE, not URIorCURIE
Ben: with '[]' it's a SafeCURIE so it's just a wording change
RESOLUTION: change the wording from URIorCURIE to URIorSafeCURIE
<markbirbeck> http://www.w3.org/TR/rdfa-syntax/#sec_6.3.1.
Mark: back on @content ...
... should we use inline markup everywhere whenever we can and minimize use
of @content?
... e.g. use something other than META?
Ralph: some of the @content examples have other
pedagogical uses and I wouldn't want to do a wholesale replacement
... and about the "small" changes to the processing rules for keeping
"useless" nodes?
Mark: they're in the CVS and will be in the next editors' draft
ACTION: Ben send announcement of @instanceof change and diffs to processing rules [recorded in http://www.w3.org/2008/05/01-rdfa-minutes.html#action16]
Ben: I'll take a look at the timeline in the
wiki
... the SWD timeline sent on Tuesday should be easy for us to meet
Ralph: regrets for next week
Mark: also regrets for next week
<markbirbeck> There is only one use of @content that should use inline text, and it's in Appendix A.
<ShaneM> Appendix A? really? Appendix A is the DTD implementation isn't it?
<markbirbeck> (I mention that to save people doing a scan.)
<ShaneM> oh.... that appendix A. didn't we remove that?
<ShaneM> we voted to remove that appendix. It is no longer in the source.
<ShaneM> Sorry - fell off the call and can't call back in. conference is restricted.
<Ralph> yeah, in fact Appendix A should use <h1 about="" property="dc:title">Internet Applications</h1>
[adjourned]
<Ralph> (thanks, Mark; I'm happy with your conclusion :)
<ShaneM> I have to go anyway. Ben, do you want me to publish right now, or wait until you have reviewed Mark's mail from last night?
<ShaneM> I have made the changes you requested during the call already.
<benadida> no publish right now.
<benadida> no, COMMA, publish right now :)_