W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > June 2008

meeting record: 2008-06-05 RDF-in-XHTML task force

From: Ralph R. Swick <swick@w3.org>
Date: Thu, 05 Jun 2008 12:32:39 -0400
Message-Id: <5.1.0.14.2.20080605123059.043f0678@127.0.0.1>
To: public-rdf-in-xhtml-tf@w3.org, public-swd-wg@w3.org

The minutes of today's RDFa telecon [1] are now available for review.

  [1] http://www.w3.org/2008/06/05-rdfa-minutes

----

                            RDF-in-XHTML TF

05 Jun 2008

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Jun/0003.html

   See also: [3]IRC log, previous [4]2008-05-29

      [3] http://www.w3.org/2008/06/05-rdfa-irc
      [4] http://www.w3.org/2008/05/29-rdfa-minutes.html

Attendees

   Present
          Ralph Swick, Steven Pemberton, Manu Sporny, Shane McCarrob,
          Ben Adida, Mark Birbeck

   Regrets
          Michael Hausenblas

   Chair
          Ben

   Scribe
          Ralph

Contents

     * Topics
         1. Action Items
         2. ISSUE-111: XSLT conformance levels
         3. ISSUE-113: document fragments
         4. TAG comments
         5. Clean Room implementation status
     * Summary of Action Items
     _____________________________________________________

Action Items

   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
   [12]http://www.w3.org/2008/05/29-rdfa-minutes.html#action06]

     [12] 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
   [13]http://www.w3.org/2007/11/15-rdfa-minutes.html#action01]
   [CONTINUES]

     [13] http://www.w3.org/2007/11/15-rdfa-minutes.html#action01

   Ben: I believe INRIA will be dual-licensing their code under LGPL

   ACTION: Ralph confirm whether LGPL is ok with W3C [recorded in
   [14]http://www.w3.org/2008/06/05-rdfa-minutes.html#action03]

     [14] 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
   [15]http://www.w3.org/2008/05/08-rdfa-minutes.html#action10]
   [CONTINUES]

     [15] http://www.w3.org/2008/05/08-rdfa-minutes.html#action10

   Manu: I've sent email, need to look for a response

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

     [16] http://www.w3.org/2008/03/13-rdfa-minutes.html#action12

   ACTION: Michael to determine which useless-triples test cases to
   remove and which to add. [recorded in
   [17]http://www.w3.org/2008/05/08-rdfa-minutes.html#action12]
   [CONTINUES]

     [17] http://www.w3.org/2008/05/08-rdfa-minutes.html#action12

   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
   [18]http://www.w3.org/2008/06/05-rdfa-minutes.html#action07]

     [18] http://www.w3.org/2008/06/05-rdfa-minutes.html#action07

   ACTION: Ralph to help Ben with Last Call Comment report [recorded in
   [19]http://www.w3.org/2008/06/05-rdfa-minutes.html#action08]

     [19] http://www.w3.org/2008/06/05-rdfa-minutes.html#action08

ISSUE-111: XSLT conformance levels

   -> [20]issue 111

     [20] http://www.w3.org/2006/07/SWD/track/issues/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: document fragments

   -> [21]issue 113

     [21] http://www.w3.org/2006/07/SWD/track/issues/113

   <benadida> I'd drafted [22]public-rdf-in-xhtml-tf/2008May/0030.html

     [22] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008May/0030.html

   Ben: we've been careful to specify that triples are only present in
   complete documents

   <ShaneM> [23]ED-rdfa-syntax-20080603/#sec_3.9.

     [23] http://www.w3.org/MarkUp/2008/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
   [24]http://www.w3.org/MarkUp/2008/ED-rdfa-syntax-20080603/#sec_3.9.

     [24] 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
   [25]http://www.w3.org/2008/06/05-rdfa-minutes.html#action09]

     [25] http://www.w3.org/2008/06/05-rdfa-minutes.html#action09

TAG comments

   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
   [26]http://www.w3.org/2008/06/05-rdfa-minutes.html#action10]

     [26] 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!

Clean Room implementation status

   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]

Summary of Action Items

   [NEW] ACTION: Manu complete test suite [by Thursday 12 June]
   [recorded in
   [27]http://www.w3.org/2008/06/05-rdfa-minutes.html#action07]
   [NEW] ACTION: Mark to tweak paragraph 3.9 of the spec on fragments.
   [recorded in
   [28]http://www.w3.org/2008/06/05-rdfa-minutes.html#action09]
   [NEW] ACTION: Ralph confirm whether LGPL is ok with W3C [recorded in
   [29]http://www.w3.org/2008/06/05-rdfa-minutes.html#action03]
   [NEW] ACTION: Ralph to help Ben with Last Call Comment report
   [recorded in
   [30]http://www.w3.org/2008/06/05-rdfa-minutes.html#action08]
   [NEW] ACTION: Shane produce a CR-ready draft for SWD and XHTML2 WGs
   to approve [recorded in
   [31]http://www.w3.org/2008/06/05-rdfa-minutes.html#action10]

     [27] http://www.w3.org/2008/06/05-rdfa-minutes.html#action07
     [28] http://www.w3.org/2008/06/05-rdfa-minutes.html#action09
     [29] http://www.w3.org/2008/06/05-rdfa-minutes.html#action03
     [30] http://www.w3.org/2008/06/05-rdfa-minutes.html#action08
     [31] http://www.w3.org/2008/06/05-rdfa-minutes.html#action10

   [PENDING] ACTION: Ben followup with Fabien on getting his RDFa GRDDL
   transform transferred to W3C [recorded in
   [32]http://www.w3.org/2007/11/15-rdfa-minutes.html#action01]
   [PENDING] ACTION: Manu to reach out to Slashdot and attempt to get
   RDFa integrated into Slashdot. [recorded in
   [33]http://www.w3.org/2008/05/08-rdfa-minutes.html#action10]
   [PENDING] ACTION: Michael to create 'RDFa for uF users' on RDFa Wiki
   [recorded in
   [34]http://www.w3.org/2008/03/13-rdfa-minutes.html#action12]
   [PENDING] ACTION: Manu to determine which useless-triples test cases
   to remove and which to add. [recorded in
   [35]http://www.w3.org/2008/05/08-rdfa-minutes.html#action12]

     [32] http://www.w3.org/2007/11/15-rdfa-minutes.html#action01
     [33] http://www.w3.org/2008/05/08-rdfa-minutes.html#action10
     [34] http://www.w3.org/2008/03/13-rdfa-minutes.html#action12
     [35] http://www.w3.org/2008/05/08-rdfa-minutes.html#action12

   [DONE] ACTION: 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
   [36]http://www.w3.org/2008/05/29-rdfa-minutes.html#action06]

     [36] http://www.w3.org/2008/05/29-rdfa-minutes.html#action06

   [End of minutes]
     _____________________________________________________


    Minutes formatted by David Booth's [37]scribe.perl version 1.133
    ([38]CVS log)
    $Date: 2008/06/05 16:30:54 $

     [37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [38] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 5 June 2008 16:33:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 June 2008 16:33:39 GMT