See also: IRC log, previous 2008-06-12
<ShaneM> I am trying to wrap xhtml 2 call
<Ralph> 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.
Ben: I thought TimBL was comfortable with this in his response.
<Ralph> 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: 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>