Re: Comments on RDFa in XHTML: Syntax and processing

Ralph and members of the pertinent workgroups:

Thank you for your careful attention to my concerns.  I provide some 
detailed responses below, but to get immediately to the question that 
tends to be of greatest interest to working groups that are trying to move 
forward:  yes, the responses and proposals you give below are acceptable 
to me should you wish to move forward without further changes.  Thus, the 
additional suggestions I make below are just for your consideration:  if 
you find them helpful, feel free to adapt some or all, and if not that's 
OK too.  Either way, feel free to proceed without further coordination 
with me.  Of course, if you would find further discussion helpful I will 
be glad to continue, and if you do make further changes I'd be curious to 
know what they are.

Ralph Swick writes:

> > At 05:27 PM 8/21/2008 -0400, noah_mendelsohn@us.ibm.com wrote:
> ...
> >* HTML or XHTML? 
> >
> >The title of the draft refers to XHTML.  Section 3.10 says, somewhat
> >confusingly: "The aim of RDFa is to allow a single [RDF graph] to be
> >carried in various types of document mark-up. However, this
> >specification deals only with RDFa in XHTML"  This leaves it a bit
> >unclear as to what it is from this Recommendation that might apply
> >beyond XHTML.
> 
> We've been intentionally a bit vague on that point, as one 
interpretation
> of the Semantic Web Deployment and XHTML2 Working Groups' charters
> is that they only consider [X]HTML.  A purpose of XHTML modularization
> is to construct modules that can work with non-HTML languages and
> SVG has been noted in our discussions as a possible example.

Well, I understand, but I'm still not convinced that the somewhat vague 
exposition is the best way to deal with that situation.  Might it be 
better to explicitly say something along the lines of:  "The charters of 
the Semantic Web Deployment and XHTML2 Working Groups are focused 
specifically on [X]HTML.  Although this specification is therefore 
normative only for use of RDFa in XHTML and HTML, informal efforts have 
been made to provide a design that will be suitable for use in other 
languages as well."

...and, if you wish follow that with:

"Specifications for such other languages MAY normatively reference this 
Recommendation and thus may provide for use of RDFa markup, with the 
caveat that there is currently no W3C working group chartered to maintain 
this specification for such broader use."

(A bit clumsy, and you can probably find better ways to say it.  I also 
feel the need to re-emphasize that I am speaking for myself and not for 
the TAG in all of this.  Anyway, I'm wondering whether it would be better 
to tell the story carefully, whatever it is.  The current text seems 
subject to multiple interpretations, and I'm not sure that's ever for the 
best.)
 
> >  After all, it says that everying in this specification is XHTML
> >only.  Also, the abstract says: "RDFa is a specification for
> >attributes to be used with languages such as HTML and XHTML to
> >express structured data."  That suggests applicability beyond XHTML,
> >but only to HTML-family languages.
> 
> We will revise this sentence to read "RDFa is a specification for
> attributes to express structured data in any markup language.  This
> document specifies RDFa and its use with XHTML."

Fine.  And/or see suggestion above.

> This more accurately reflects our intent and our design rationale but
> acknowledges the more limited scope of our Group charters.
> 
> >I suggest that the whole question of which sorts of languages are
> >covered, and in particular whether there is any normative
> >applicability to non-XHTML variants of HTML, should be clarified.
> 
> We have attempted to state a position in the non-normative RDFa Primer
> (latest editors' draft not yet published, at [1]).  The scope of this 
particular
> specification is explicitly more restricted as you have observed.
> 
>   [1] http://www.w3.org/2006/07/SWD/RDFa/primer/20080813/#id0x0c4b79a0
> 
> The HTML Working Group charter states
> 
>   "The HTML WG is encouraged to provide a mechanism to permit
>   independently developed vocabularies such as Internationalization
>   Tag Set (ITS), Ruby, and RDFa to be mixed into HTML documents.
>   Whether this occurs through the extensibility mechanism of XML,
>   whether it is also allowed in the classic HTML serialization, and
>   whether it uses the DTD and Schema modularization techniques,
>   is for the HTML WG to determine."
>   -- http://www.w3.org/2007/03/HTML-WG-charter#deliverables
> 
> We believe that this RDFa design could be accommodated in non-XHTML
> variants of HTML through any of those mechanisms described in that
> charter.  We look forward to a time when the HTML Working Group would
> be ready to collaborate on demonstrating this.

I think having explanations in the primer is fine, but I do think the 
applicability of the Recommendation is best dealt with normatively. 
Eventually, someone will ask whether use of RDFa in language XXX is 
normative just by the existence of the RDFa Syntax Rec (I think no), 
and/or whether it is appropriate for it to be made normative by explicit 
reference from the specification for language for XXXX (I think the answer 
is yes.)  So, as suggested above, I think it would be better to clarify 
the groundrules in your normative sections.

 
> >-----------------
> >
> >* Are you defining conformance for markup, a processor, or both? 
> >
> >The abstract says:  "This document is a detailed syntax specification
> >for RDFa..."  (no mention of processors) 
> >
> >Section 4.3: defines conformance for a "processor", presumably a
> >piece of software or maybe hardware, with requirements such as:
> >"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. "
> >It also quite nearby says:  "This specification uses the term
> >[default graph] to mean all of the triples asserted by a document
> >according to the Processing Model section." 
> 
> The specification defines conformance requirements in 3 groupings:
> 
> 4.1 talks about markup conformance
> 4.2 talks about user agent conformance
> 4.3 talks about processor conformance

Yes

> >I tend to feel that specification of a lanuage and its mapping to
> >things like default graphs is quite a different thing from the
> >specification of a piece of software with certain required outputs.
> >Indeed, one can imagine lots of different software that would do
> >useful things with RDFa but that would, for one reason or another,
> >never bother to construct the entire default graph.  Is such software
> >non-conforming?

> If the observable behavior of such software is indistinguishable from
> software that does construct the full default graph then it is
> impossible to prove non-conformance and so we would not care.

On this one I'm not convinced.  Let's say I build a piece of software that 
exposes exposes to applications exactly one triple from the graph.  That's 
all the API I've built can do;  it's a special purpose API that returns if 
available, say, the email address for some requested principal.  The 
triple is correct, and so the output is indistinguishable from that which 
would be produced by software that first built the whole graph, and then 
provided the one triple.  The software is useful and it does what my 
application needs;  it's also easier to write and debug than something 
that exposes the whole graph.

The problem is, your draft says my software is nonconforming.  The draft 
says that conforming software must "MUST make available to a consuming 
application a single [RDF graph] containing all possible triples".  My 
software fails that test, because it exposes only one triple.  To make it 
conforming, I have to add APIs to my software that will expose all the 
other triples, even though I know that my particular application will 
never call for those other triples. 

I would be much happier if you said something like:  "A conforming RDFa 
Processor MUST make available to a consuming application a single [RDF 
graph] containing triples generated by using the rules in the Processing 
Model section.  The graph made available MUST either be a complete graph, 
I.e. containing all possible triples generated by using the rules in the 
Processing Model section, or else a graph containing a subset of those 
triples." 

And if you like...

"RDFa processors designed for general purpose use SHOULD provide the 
complete graph."
 
> >Thus my preference, and its only a preference, would be to see the
> >definition of default graph retained for reference by other
> >specifications, but the definition of processor conformance moved
> >either to a separate document or perhaps to a normative appendix of
> >the syntax and processing document.
> 
> While we appreciate that this suggestion might lead to a more modular
> specification, the concept of the default graph is currently so
> intertwined in the various sections that the group feels changing it
> at this stage of the process would add more delay than could be
> justified.  We have recorded this suggestion as our [ISSUE-126] for
> some future revision of the specification.
> 
> >  I think a more appropriate title for such a section might be:
> >"Conformance requirements for general purpose RDFa processors",
> >signalling that general purpose software that builds the whole graph
> >is only one kind of useful software that you might want to deploy for
> >RDFa.
> 
> Noted for a possible future version of the specification.
> 
>   [ISSUE-126] http://www.w3.org/2006/07/SWD/track/issues/126

OK, see above.

> >-----------------
> >
> >Section 4.1: 
> >
> >"3. The start tag of the root element of the document must explicitly 
contain an xmlns declaration for the XHTML namespace [XMLNAMES]. The 
namespace URI for XHTML is defined to be http://www.w3.org/1999/xhtml. 
> >
> >        Sample root element 
> >        <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">" 
> >
> >It's not entirely clear whether this requirement would be satisified by 
a different root element like this, since it does have an xmlns 
declaration for the XHTML namespace: 
> >
> >        <html xmlns:prefix="http://www.w3.org/1999/xhtml" 
xml:lang="en">" 
> >
> >This of course defines a completely different root element name, and I 
suspect it's not intended to be conforming.  Either way, I suggest that 
the rule be clarified. 
> 
> We believe you are pointing out that a root element such as
> 
>   <html xmlns='my_private_ns' xmlns:html='http://www.w3.org/1999/xhtml'>
> 
> would be non-conformant and we agree.
> 
> We will clarify the wording to 
> 
>   "The start tag of the root element of the document MUST explicitly
>   contain a default namespace declaration for the XHTML namespace ..."

Good, thank you.

> >----------------- Editorial Comments -----------------
> >
> >Section 3.10: 
> >
> >        "is always an [URI reference]" 
> >        "statement can be an [URI reference]" 
> >
> >Should those be "a" URI reference?  (could be my grammar is rusty, but 
it seems the same case as "a yellow banana" vs. "an yellow banana") 
> 
> We agree and will incorporate this change.

Thank you.

> >----------------- 
> >
> >Section 4.1: 
> >
> >        "Such a document MUST meet all of the following critera:
> >
> >        1. ... 
> >        2. ... 
> >        3. ... 
> >        4. There SHOULD be a DOCTYPE 
> >        5. There SHOULD be @version 
> >        6. There SHOULD be @profile...." 
> >
> >The nesting of SHOULDs within a MUST seems odd.  I suggest you split
> >this into two sets of clauses, one labeled as requirements that MUST
> >be met, and a second with desideratat that SHOULD be attended to.
> 
> Accepted.  We will capitalize the existing MUST in the first 3 items and
> remove it from the introductory sentence.
> The introductory sentence and first three bullets will read
> 
>   "Such a document satisfies the following criteria:
> 
>    1. The document MUST conform ...
>    2. The local part of the root element of the document MUST be ...
>    3. The start tag of the root element of the document MUST explicitly
>      contain a default namespace declaration for the XHTML namespace
>      [XMLNAMES]. The namespace URI for XHTML is defined to be
>       http://www.w3.org/1999/xhtml."
> 

Good, thank you.

> >-----------------
> >
> >I hope these comments are helpful to you in carrying forward the work
> >on RDFa.  Thank you very much.
> 
> We thank you for your interest and assistance in improving the RDFa
> specification.   Your comments have been recorded as [ISSUE-127]
> for purposes of tracking CR review.
> 
>   [ISSUE-127] http://www.w3.org/2006/07/SWD/track/issues/127
> 
> We hope this reply is satisfactory to you; please let us know.

Yes.  As noted above, I have some residual concerns, but not of sufficient 
strength to ask that you delay publication to get consensus from me.  That 
said, I hope your group will give at least some consideration to the 
followup points I've made above.
 
> -Ralph
>  on behalf of the RDF-in-XHTML Task Force of the
>  XHTML2 Working Group and the Semantic Web Deployment Working Group

Thank you again for the opportunity to comment on this very important 
work.

Noah
(speaking for myself and not necessarily for the W3C TAG)

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Friday, 29 August 2008 18:35:34 UTC