See also: IRC log, previous 2008-05-29
ACTION: [DONE] Shane draft a TAG response along the lines of "we will update the namespace document, both the prose and the machine-readable and all documents of type XHTML1 have RDF triples" [recorded in http://www.w3.org/2008/05/29-rdfa-minutes.html#action06]
Shane: this was integrated into Steven's message
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 believe INRIA will be dual-licensing their code under LGPL
ACTION: Ralph confirm whether LGPL is ok with W3C [recorded in http://www.w3.org/2008/06/05-rdfa-minutes.html#action03]
ACTION: Manu to reach out to Slashdot and attempt to get RDFa integrated into Slashdot. [recorded in http://www.w3.org/2008/05/08-rdfa-minutes.html#action10] [CONTINUES]
Manu: I've sent email, need to look for a response
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: Michael to determine which useless-triples test cases to remove and which to add. [recorded in http://www.w3.org/2008/05/08-rdfa-minutes.html#action12] [CONTINUES]
Manu: I'll take this action from Michael
... I've already removed the tests that should be removed
... I think there are 3 useless-triple test cases that should be added
ACTION: Manu complete test suite [by Thursday 12 June] [recorded in http://www.w3.org/2008/06/05-rdfa-minutes.html#action07]
ACTION: Ralph to help Ben with Last Call Comment report [recorded in http://www.w3.org/2008/06/05-rdfa-minutes.html#action08]
-> issue 111
Manu: I've been talking with Ivan and Micah
Dubinko about this
... XSLT implementations will have two problems: whitespace preservation and
inclusion of namespaces in XML literals
... Micah thinks this will be a black mark against RDFa if it requires
whitespace preservation
... and Ivan doesn't like the way we're doing namespaces in XML literals
<ShaneM> I would just say it is a "SHOULD"
Manu: Micah suggests that the spec make
whitespace preservation optional
... either for XSLT alone or for all implementations
Ben: I'm opposed to doing something special for
XSLT1
... if we make whitespace preservation optional, we should do it for all
implementations
Ralph: +1 to not treating XSLT differently
Ben: if we do make these optional, how will
that affect interoperability?
... will people not be able to rely on XML literals?
Shane: we decided that whitespace should be
preserved
... and we said the underlying spec determines how namespaces are preserved
in XML literals
... if we make namespace preservation optional, that reduces the utility of
that part of the spec in my opinion
Manu: the namespace problem is that XSLT1
doesn't appear to be able to add xmlns attributes to the top-level element
... Ivan did say he thought there was a way to get @xmlns into every element
but these would overwrite any other @xmlns in those elements, so that would
be wrong
Ben: not carrying the namespaces inside XML literal would simply be wrong
Manu: there are some large practical implementations
Ralph: we are not required to show that all
implementations fully implement the spec
... we are only required to show that all features have been implemented
somewhere
Shane: Ben made an important point that we
should not make an exception for broken tools
... if there are tools that can't support the spec, then those are not
suitable implementation tools
Ben: but these shortcomings can point to design
issues in the spec
... I don't feel that the XML Literal design is wrong
... however, the whitespace preservation could be changed
Steven: XML does not specify whether whitespace
is preserved or not
... XML says there are two sorts of whitespace preservation; default and
preserved
... you don't know whether 'default' preserves whitespace
... there's no way XSLT can know how the source language specifys whitespace
preservation
... and the default may be 'preserve'
... so XSLT has no business touching whitespace at all
Ben: so I propose we make no change
<msporny> +1
Ralph: +1 to no change
<ShaneM> +1 for no change
Mark: agree
... could we slightly change the wording to say 'if you support XML Literals,
then this is how you should support them'
... i.e. we could allow implementations to not support XML Literal
Ralph: I'd rather we consider these as
implementation bugs and let the community experience determine how important
it is for any given implementation to fix its bug
... we decided in favor of whitespace preservation on the basis that those
(few?) applications who really cared had no other way to get whitespace
... the deployment experience can show whether those applications really
influence implementations
<benadida> PROPOSAL: in response to ISSUE-111, we do not believe a change in the spec is necessary. We believe that, architecturally, whitespace and namespace preservation are important. We rely on deployment experience to inform the specifics of complete implementations.
<Steven> Here's a case <pre about="something" property="my:implementation">function f(a); ... lots of lines ...</pre>
<benadida> PROPOSAL: in response to ISSUE-111, we do not believe a change in the spec is justified. We believe that, architecturally, whitespace and namespace preservation are important. We rely on deployment experience to ....
PROPOSAL: in response to ISSUE-111, we do not believe a change in the spec is justifiable. We believe that, architecturally, whitespace and namespace preservation are important. We will rely on deployment experience to inform specific implementation techniques.
<benadida> +1
<msporny> +1
<Steven> +1
<ShaneM> +1
RESOLUTION: in response to ISSUE-111, we do not believe a change in the spec is justifiable. We believe that, architecturally, whitespace and namespace preservation are important. We will rely on deployment experience to inform specific implementation techniques.
-> issue 113
<benadida> I'd drafted public-rdf-in-xhtml-tf/2008May/0030.html
Ben: we've been careful to specify that triples are only present in complete documents
<ShaneM> ED-rdfa-syntax-20080603/#sec_3.9.
Ben: any objections to 0030 ?
<markbirbeck> I think "dataRSS" is "DataRSS".
<Steven> Two many "only"s in that sentence
<ShaneM> kk thanks
Ralph: the critical sentence is the first one in the last paragraph of 3.9. I support this
<msporny> +1 to the language in http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080603/#sec_3.9.
<Steven> "and thus only yield their true triples only once they are placed"
Mark: is this actually responding to the
question?
... in the spirit of allowing experimentation, I'd prefer not to be so
strict
... just say that to determine the triples you need the full document
context
<Steven> What about multi namespace documents?
<Zakim> Steven, you wanted to discuss follow your nose and to talk about fragments
Steven: my worry is the wording that triples
are only revealed in the full document context
... I'd like SVG fragments to contain triples
Ben: I believe there will be applications that
do extract triples from DataRSS
... but I think we need to defer the standardization of that for a future
version
Mark: the current language is more rigid than we need
Steven: I'd say "only once they are placed in complete documents"
Mark: if we're trying to address "be careful when you put fragments in" then just say that
PROPOSE: s/fragments only have all of their context and thus only yield their true triples only once they are placed within"/triples in fragments must be interpreted in the context of a"
Steven: I'm just asking that RDF triples be extractable from SVG+
Shane: but this spec is not covering SVG
<Steven> But it is covering the xhtml namespace
<ShaneM> I think that means it would read like this: <p>While these uses are legitimate, and their results may be predictable if the fragments are carefully constructed, remember that XHTML+RDFa is not specified for XHTML fragments; triples in fragments must be interpreted in the context
<ShaneM> of a complete XHTML+RDFa document.
<ShaneM> Consequently, authors should craft these fragments carefully and
<ShaneM> consider the various ways in which a given fragment can be framed.</p>
Ralph: and, specifically, in response to Micah's request that opened issue 113 we're explicitly _not_ specifying processing rules for fragments
Steven: but some folks claim there is no XHTML
on the Web today because they strictly apply the specifications and don't
find documents that use the correct media type
... it may depend on what Micah means by 'fragments'
<markbirbeck> "A common situation will be to take fragments of XHTML+RDFa and move them from one document to another. This may be through the use of tools, such as cut-and-paste, or through snippets of code that are provided by organisations such as Creative Commons. However, authors should be aware that this specification does not say how these fragments should be processed outside of a document (although future versions will address this). They can of course be in
Steven: if he's thinking of multiple namespace documents then it is bad to exclude RDFa from them
Ralph: Micah's message specifically referred to copy-and-paste
Ben: WAI PF WG also mentioned fragments
Steven: but if Micah is only referring to bits of XHTML lying around, then we're fine
<benadida> PROPOSE: resolve ISSUE-113 as "we will not be specifying processing rules for fragments, though a future version of the spec may do so. We don't rule out the use case."
Ralph: +1 to proposal
<msporny> +1
<markbirbeck> +1
Shane: ok
RESOLUTION: close ISSUE-113 as "we will not be specifying processing rules for fragments, though a future version of the spec may do so. We don't rule out the use case."
ACTION: Mark to tweak paragraph 3.9 of the spec on fragments. [recorded in http://www.w3.org/2008/06/05-rdfa-minutes.html#action09]
Steven: we're discussing the wording of the
response
... issue about the media type
... our reply is along the lines of 'HTML and XHTML have always contained
assertions and this is just another way to express those assertions'
... I think this is completely independent of media type because of
mixed-namespace documents
... you can't tell from the media type whether a document actually uses the
XHTML namespace
... our XHTML namespace tells you how to interpret the XHTML attributes [in a
mixed-namespace document]
Shane: the got-ya here is that some TAG
participants view media type as an announcement mechanism
... and we're saying "no, media type is not an announcement mechanism"
Steven: ok, now I'm ready to send the response to the TAG
ACTION: Shane produce a CR-ready draft for SWD and XHTML2 WGs to approve [recorded in http://www.w3.org/2008/06/05-rdfa-minutes.html#action10]
<Ralph> Shane++
<ShaneM> Note that the week of the 16th is ugly for a transition call - please start scheduling it ASAP!
Ben: I'm well along with this
... the only problems I'm having have nothing to do with the spec
... the general structure with deep @rel, chaining, etc. is working for me
just fine in Ruby
<Ralph> Ben++
[adjourned]