DRAFT Re: Comments on RDFa in XHTML: Syntax and processing

Though Noah's comments are well past our requested CR comment
deadline, I think we can and should respond to them with small editorial
changes only.

Here's a draft of how we might respond:

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.

>  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. 

[I believe it would be an editorially-consistent change to revise the
cited 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."]

>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]).

  [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.

>----------------- 
>
>* 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." 
>
>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?

Fair point.  This specification is indeed a procedural one describing
how the default graph is to be constructed.   A tool that omitted
construction of parts of the graph that it knew it would not use would
seem not to violate the spirit of this specification.  If that tool were to
provide an API for others to access the graph then it would likely
be non-conforming if it did not then produce all the specified triples.

>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 Working Groups feel that such a change
at this stage of the process would add more delay than could
be justified.  We will be glad to record this suggestion 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.

>----------------- 
>
>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 ..."

[wording thanks to Shane]

>----------------- 
>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") 

['a' sounds better to me as well.  I propose Shane decide.]

>----------------- 
>
>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 move the MUST down into the first 3 items and
remove it from the introductory sentence.

[thanks to Shane for this suggestion.]

>----------------- 
>
>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
specification.

Received on Wednesday, 27 August 2008 16:29:34 UTC