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

Hi all,

The minutes say:

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

So this is me checking in and saying that I have no problem with the
two changes that were made.

(In fact, I strongly welcome the first one.)

Regards,

Mark

On Thu, Jun 19, 2008 at 6:36 PM, Ralph R. Swick <swick@w3.org> wrote:
>
> 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/
>
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 19 June 2008 20:31:17 UTC