meeting record: 2008-06-19 RDF-in-XHTML Task Force

The record of today's RDFa telecon [1] is available for review.  Thanks,
Manu, for scribing this telecon.

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

We did not do an Action review so I copied the action status from
the previous meeting record.  I took the liberty to mark one action
completed that's already on other records as having been done.
Other actions may also be done but we'll look at them at a future telecon.

A text snapshot follows:

----

                        RDF in XHTML Task Force

19 Jun 2008

   [2]Agenda

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

   See also: [3]IRC log, previous [4]2008-06-12

      [3] http://www.w3.org/2008/06/19-rdfa-irc
      [4] http://www.w3.org/2008/06/12-rdfa-minutes

Attendees

   Present
          Ralph Swick, Manu Sporny, Shane McCarron, Ben Adida

   Regrets
          Steven Pemberton, Mark Birbeck

   Chair
          Ben Adida

   Scribe
          Manu Sporny

Contents

     * Topics
         1. TimBL's comments
         2. Default Graph Language per TimBL's comment.
     * Summary of Action Items
     _____________________________________________________

   <ShaneM> I am trying to wrap xhtml 2 call

TimBL's comments

   <Ralph>
   [9]http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#docconf

      [9] http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#docconf

   Ralph: There are two remaining technical points that need to be
   clarified.
   ... The document type and extra triples that are generated.
   ... regarding document conformance, the concern is around SHOULDs
   for the DOCTYPE and @profile.
   ... My proposal after the conversation with Tim is to put the
   reference to DOCTYPE and @profile into a non-normative appendix
   ... The reasoning is that these are both for the convenience of
   implementations that need these facilities. They are not required
   for the document to assert it has triples.
   ... Neither DOCTYPE nor @profile are essential for asserting
   triples.

   Ben: What about @version

   Ralph: Tim has not expressed worry about @version.

   Ben: We should make this consistent, so we should include @version.

   Ralph: Good point, we should include it in the appendix.

   Shane: I though this was about SHOULD/MUST for detection of triples.

   Ralph: Not really, each of the three was meant to assert whether or
   not the document asserts the triples.

   Ben: we all agree that triples are kicked off via the namespace
   document

   Shane: The constraints from XHTML modularization have nothing to do
   with triple generation.
   ... They have to do with the announcement of the type of document
   that is being delivered.
   ... We always provide a way for document authors to specify the type
   of document they're delivering.

   Ralph: The GRDDL spec is clear that either @profile or namespace
   document is sufficient. We're doing the namespace document, so we're
   covered there.

   Ben: I thought we were always clear about changing the definition of
   XHTML with modularization.
   ... So we're moving to an appendix or changing to MAY.
   ... Isn't that change substantive.

   Ralph: There's another way to look at it... we need to consult with
   XHTML 2 WG.
   ... The spec currently says SHOULD, and what we're being told is
   that SHOULD is confusing.
   ... SHOULD means that implementations should complain if documents
   don't have this, but we're not attempting to be that strong.
   ... It's not clear what the triple protocol is with these three
   SHOULDs.
   ... It's a different kind of IETF SHOULD...

   Shane: It is possible that XHTML2 WG is using the term SHOULD in a
   way that other groups use it... and if that's the case we should
   change it.
   ... We don't think that SHOULD means "agents should complain". If
   that's the case, we should be saying "MAY".
   ... Usually MAY is an optional behavior, and is a warning to
   implementers to not depend on the behavior.
   ... We now have @version - it would be nice to say MUST include
   @version.
   ... We are attempting to do 2 things with this.
   ... Define a document type and define a method to detect that
   triples could be extracted from the document.

   Ralph: The definition of the markup language is done through the
   namespace URL.

   Manu: So we have DOCTYPE and then we have @version and we have
   @profile.
   ... In the future, it seems like people want to get rid of DOCTYPE.
   So isn't @version going to be necessary in the future?

   Shane: AFAIK, yes.

   Ralph: If somebody creates a schema that produces different triples,
   we would be uncomfortable with that. You must state the @version if
   you want to be clear.

   Ben: Is there going to be a way to follow your nose using a
   combination of the default namespace and @version.

   Ralph: If the namespace document identified triples that mapped to
   the @version, then you could follow your nose.

   Shane: We need to figure out the mapping, that's all.
   ... So we could support follow your nose with this approach.

   Ben: So DOCTYPE and @profile are not necessary, but @version could
   be.

   Ralph: If we say that @version is a MUST, then we might be
   suggesting that the XHTML1 triples were always there.

   Ben: No @version should be a SHOULD, and the XHTML1 triples have
   always been there.

   Shane: There is a difference between stating the document type and
   stating that there are triples in the document.

   Ben: Let's take the existing document into consideration.
   ... We now have a consistent internal story, what do we need to do
   to the current document.
   ... If the namespace document contains a GRDDL @profile, the
   document does not.

   Shane: GRDDL states that you should use @profile in XHTML documents.

   Ben: No, don't think that's the case.
   ... GRDDL makes most sense at the namespace level, not the instance
   level.

   Shane: TimBL wants the @profile to be in a non-normative appendix.

   Ralph: He wants us to be clear.

   Shane: We've agreed to change the namespace document.
   ... Let's remove @profile.

   Ralph: Don't think that would be a good move.
   ... We had that in there mostly for broken GRDDL implementations.
   ... So the solution to the deployment issue is to add an
   non-normative appendix.
   ... About the procedural concern about this being substantiative, we
   can mark it as a feature at risk.
   ... Informative appendix H is at risk - we could say.

   Ben: This is editorial because if you build an implementation of
   RDFa, it will still work after this change is in there.

   Ralph: We have 3 items that are SHOULD and none of them are
   necessary to find triples.

   Shane: We have an appendix now that defines the DTD and is
   normative.
   ... That appendix defines the system identifer for DTDs.
   ... The SHOULD about the DTD should be removed to an appendix. We
   already say that you SHOULD use DOCTYPE.

   Ralph: The appendix says here is the normative system identifier if
   you want to use it.
   ... We could leave it implicit that the way you use it is to put
   DOCTYPE in there.
   ... No need to write anything more informative.

   Ben: Why not do it for clarity's sake.

   Shane: We need this appendix.
   ... for validation.

   <Ralph> PROPOSE: move the two items "SHOULD be a DOCTYPE" and
   "SHOULD be a @profile" from Section 4.1 to a new Informational
   Appendix "Deployment Advice"

   Ben: So it sounds like we have an appendix that has current
   deployment advice. Use DOCTYPE and @profile if you want.

   <benadida> +1

   <msporny> +1

   Shane: We should insert the appendix before the references.

   Ralph: Sure

   Ben: Sure.

   RESOLUTION: move the two items "SHOULD be a DOCTYPE" and "SHOULD be
   a @profile" from Section 4.1 to a new Informational Appendix
   "Deployment Advice"

   Ben: I'll chat with Mark and Steven about this to make sure they're
   okay with this.

   Ralph: We'll probably need some documentation from XHTML2.

   Ben: We agree that this is an editorial change.
   ... We don't need a formal vote on this.

Default Graph Language per TimBL's comment.

   Ben: I thought TimBL was comfortable with this in his response.

   <Ralph>
   [10]http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#processor
   conf

     [10] http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#processorconf

   Ralph: The [default graph] language is fuzzy to TimBL.

   Ben: It seems he's questioning what [default graph] means.

   Ralph: There is no W3C recommendation that sufficiently defines
   [default graph]
   ... What we mean in this case is that the document has asserted
   these triples.
   ... Any other triples that the processor might choose to find, in
   this version of the spec, the document has not asserted.
   ... No W3C spec has described this.

   Ben: Can we add 3 lines to define it.

   Ralph: We should use different language

   Ben: We went through this several times, so changing the language
   might not work well for everybody.
   ... We've stuck with [default graph] for a number of reasons.

   Ralph: I know we've talked about this several times.

   Ben: Can't we just define this.

   Shane: We do, it says it right at the top of this section:
   [11]http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#processor
   conf

     [11] http://www.w3.org/MarkUp/2008/CR-rdfa-syntax-20080620/#processorconf

   Ralph: We don't say that the [default graph] holds the triples that
   are asserted by this document.

   Shane: A conforming RDFa Processor MUST make available to a
   consuming application a single [RDF graph] containing all possible
   triples generated by using the rules in the Processing Model
   section. This is called the [default graph].

   <Ralph> PROPOSE: add "The [default graph] is the graph of triples
   that are asserted by the document according to this specification."

   Ralph: We are saying that the document asserts a certain set of
   triples, we are not saying that they do not assert any other
   triples.

   Ben: I'd be happy with what you've proposed.

   <msporny> +1

   Shane: "For the avoidance of doubt, tThe [default graph] is the
   graph of triples that are asserted by the document according to this
   specification."

   <Ralph> PROPOSE: add "The RDF semantics of the document include the
   triples that are in the [default graph]."

   <Ralph> PROPOSE: add "This specification uses the term [default
   graph] to mean the graph of triples that are asserted by the
   document."

   <ShaneM> For the avoidance of doubt, the default graph contains all
   of the triples

   <ShaneM> asserted by a document according to the processing model.

   Ben: When we say [default graph] we don't mean all triples asserted
   by all languages. We mean ONLY the triples generated by the RDFa
   specification.

   Ralph: We are saying that document authors that use the processing
   model that we have described here are asserting triples.

   Ben: You're trying to say something stronger?
   ... We shouldn't allow this specification to allow OTHER triples
   defined in other documents to be placed into the [default graph]

   <benadida> he [default graph] is the graph of triples that,
   according to this specification, are asserted by the document.

   <ShaneM> PROPOSE: This specification uses the term <tref>default
   graph</tref> to mean all of the triples asserted by a document
   according to the <a href="#s_model">Processing Model</a> section.

   <ShaneM> PROPOSE:

   <ShaneM> <p><must>A conforming RDFa Processor MUST make available to
   a consuming application

   <ShaneM> a single <tref>RDF graph</tref> containing all possible
   triples generated by

   <ShaneM> using the rules in the <a href="#s_model">Processing
   Model</a> section. This is called

   <ShaneM> the <tdef>default graph</tdef>, and only contains the
   triples asserted by a document that are within this single RDF
   graph.</p>

   <ShaneM> PROPOSE:

   <ShaneM> <p><must>A conforming RDFa Processor MUST make available to
   a consuming application

   <ShaneM> a single <tref>RDF graph</tref> containing all possible
   triples generated by

   <ShaneM> using the rules in the <a href="#s_model">Processing
   Model</a> section.</must>

   <ShaneM> This specification uses the term

   <ShaneM> <tdef>default graph</tdef> to mean all of the triples
   asserted by a document according to the <a
   href="#s_model">Processing Model</a> section.</p>

   Replace sentence "This is called the [default graph]" with "This
   specification uses the term <tref>default graph</tref> to mean all
   of the triples asserted by a document according to the <a
   href="#s_model">Processing Model</a> section."

   <msporny> +1

   <Ralph> +1

   RESOLUTION: Replace sentence "This is called the [default graph]"
   with "This specification uses the term <tref>default graph</tref> to
   mean all of the triples asserted by a document according to the <a
   href="#s_model">Processing Model</a> section."

   <benadida> +1

   <ShaneM> +1

   <ShaneM> W.r.t. the new appendix C....

   <ShaneM> <sec-start "3" "a_deployment" "Deployment Advice" "" "">

   <ShaneM> <p><i>This section is informative.</i></p>

   <ShaneM> <p>Documents written using the markup language defined in

   <ShaneM> this specification can be validated using the

   <ShaneM> DTD defined in <a href="#a_xhtmlrdfa_dtd">Appendix A</a>.
   If a document author wants

   <ShaneM> to faciliate such validation, they may include the
   following

   <ShaneM> declaration at the top of their document:</p>

   <ShaneM> <p>Authors who want to be certain their documents are

   <ShaneM> transformable by <nref>GRDDL</nref> processors could

   <ShaneM> use the <code>profile</code> attribute as permitted by

   <ShaneM> the GRDDL Recommendation in the following way:</p>

Summary of Action Items

   [PENDING] ACTION: Ben followup with Fabien on getting his RDFa GRDDL
   transform transferred to W3C [recorded in
   [12]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
   [13]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
   [14]http://www.w3.org/2008/03/13-rdfa-minutes.html#action12]
   [PENDING] ACTION: Ralph confirm whether LGPL is ok with W3C
   [recorded in
   [15]http://www.w3.org/2008/06/05-rdfa-minutes.html#action03]
   [DONE] ACTION: Ralph to help Ben with Last Call Comment report
   [recorded in
   [16]http://www.w3.org/2008/06/05-rdfa-minutes.html#action08]
   [End of minutes]
     _____________________________________________________

     [12] http://www.w3.org/2007/11/15-rdfa-minutes.html#action01
     [13] http://www.w3.org/2008/05/08-rdfa-minutes.html#action10
     [14] http://www.w3.org/2008/03/13-rdfa-minutes.html#action12
     [15] http://www.w3.org/2008/06/05-rdfa-minutes.html#action03
     [16] http://www.w3.org/2008/06/05-rdfa-minutes.html#action08


    Minutes formatted by David Booth's [17]scribe.perl version 1.133
    ([18]CVS log)
    $Date: 2008/06/19 17:32:39 $

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [18] http://dev.w3.org/cvsweb/2002/scribe/

Received on Thursday, 19 June 2008 17:37:34 UTC