Re: Updated Editor's Draft available

Shane,

thanks a lot! We are getting closer...

A general issue, that I also added to my comments: I wonder whether the
spec itself should not be centred around the processing model as the
core of the spec, with all other sections being informative. At present,
section 7 (the processing model) is labelled as 'informative', ie, all
the other sections are informative. I would consider reversing that
altogether, and turn the processing model as the normative part, all the
rest being informative. In fact, most of the informative part could be
reduced a lot, and leave it to the primer (the current text still
contains lots of leftovers from the previous versions, as I noted in my
comments).

Anyway, please find, attached, a number of comments on the text.

Thanks!

Ivan

Shane McCarron wrote:
> 
> An updated Editor's Draft of rdfa-syntax is available via the Drafts
> index page at http://www.w3.org/MarkUp/Drafts
> 
> The Processing Model section of this draft is completely new, and we
> believe reflects current state of task force agreements.  The prose is
> not quite complete.  We look forward to your comments.
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

A purely stylistic comment: although the syntax allows all types of indentation, the 'usual' turtle style is to keep the predicate and object in one line. Ie, for my eyes, 

<http://internet-apps.blogspot.com/>
   dc:creator 
   <http://www.blogger.com/profile/1109404> .
   
looks very strange; either the whole triple should be in one line or it should be:

<http://internet-apps.blogspot.com/>
   dc:creator <http://www.blogger.com/profile/1109404> .
   
(Again, this is purey stylistic...)

------------------------------------------------------------------

2.4.1. CURIE syntax

I am a bit surprised to see this here, but maybe I am not up-to-date in the discussion. My understanding was that we would _not_ use the bracketed CURIE syntax after all. Ie, the value of @href and @resource would simply be URI-s and we will live with that. Am I misinformed?

Personally, I would vote for not using that syntax, in order to minimize the deviation from the host language, ie, XHTML!

------------------------------------------------------------------

3.1 Overview

The @instanceof is missing from the list at the start

------------------------------------------------------------------

3.1 Overview

The example at the beginning is wrong by virtue of the literal processing; it should be

<photo1.jpg> dc:creator "Mark Birbeck" .

(ie, not an XML literal!)

------------------------------------------------------------------

3.1 Overview

I do not understand the sentence:

"It's important to note that the various RDFa attributes can be used on any existing element of the XML dialect. "

what 'XML Dialect' are you talking about?

------------------------------------------------------------------

3.1 Overview

At the very end of the chapter you say:

"Specifically, in the case of XHTML2, it makes sense to render as much of the useful metadata as possible and use RDFa to mark up this rendered data. "

for 'political' reasons, so to say, I would prefer not to have any reference th XHTML2. RDFa has suffered a lot because people thought that this would be an XHTML2 feature only, and we have to be careful avoiding this image. Actually, I do not believe anyting you say is XHTML2 specific.

------------------------------------------------------------------

3.2 Qualifying document components

Is it allowed, in XHTML1, to have an <em> subelement for <title>? If not, let us remove it for the same reasons as my comments above...

------------------------------------------------------------------

3.2 Qualifying document components

Actually, the example uses @resource and not @href as it says in the explanatation text. Either way is fine, but it should be consistent:-)

------------------------------------------------------------------

3.3. Relating document components

Again the "RDFa allows a single XML dialect document to include multiple RDF entities" term with 'XML dialect'...

------------------------------------------------------------------

3.3. Relating document components

The example reflects XHTML2 features which we should not have. Eg:

- <link> and <meta> element in the body
- bracketed curie syntax

I guess the <link> and <meta> elements should be exchanged againsts <span>-s

------------------------------------------------------------------

4.1. Processing

@instanceof is missing from the list

------------------------------------------------------------------

4.2. Compact URIs

Just making a note again on the bracketed CURIE

------------------------------------------------------------------

4.3. Establishing the subject

I see the chapter is not complete, as I think you refer to in your comment on "@@ Example of using rel and rev to establish the subject"; it does not reflect the processing model of section 7.3....

The main isssue here, I believe, is that the statement "if a closer ancestor element includes a rel or rev attribute with no href, src or resource, then the subject is the CURIE/URI that corresponds to that parent element" is wrong. The statement (if this is the way we want to describe it) is rather something like "if a closer ancestor element includes a rel or rev attribute, then the object generated by those attribute is used as a subject for this element". But the language used in section 7 is way cleaner...

The role of @instanceof is missing altogether.

(An editing issue: I am not sure that the current structure of the chapter is really readable. I wonder whether describing the processing step for one element with the processing model as in section 7, is not a cleaner way, rather than separating the establishment of a subject and an object.)

------------------------------------------------------------------

4.3.1. The about attribute

The literal for Mark should be plain and not XMLLiteral (in the example)

------------------------------------------------------------------

4.5.1. Literal object resolution using the content attribute

the text between the two example refer to XMLLiteral. It should not.

------------------------------------------------------------------

4.5.2. URI object resolution using the href attribute

I think it should be @href and @resource. Both are allowed, with @resource taking precedence. Actually, @src, too...

------------------------------------------------------------------

4.5.3. rel without href

First of all, @resource should also be mentioned here. 

I simply do not understand the first paragraph and I don not think it is correct. As far as I know, the rule is: if there is a @rel or @rev without any @href or @resource, then a bnode is generated as an object, and this bnode will serve as a subject for all descendent elements. CURIE or @id do not play any role here.

------------------------------------------------------------------

5.1. Literals as Objects

I am sorry, but the whole section should be rewritten, because it does not reflect the current resolutions of the group and what is described in the processing model... Indeed, the generation of XML Literals or not has been changed a lot. 

------------------------------------------------------------------

5.2. Blank nodes

I am sorry, but the whole chapter reflects a previous status, and is outdated as far as the resolutions of the group are concerned... <link> and <meta> elements are not used within the <body>, and there is no such thing (afaik) as bnode CURIE. Please refer to my comment on chapter 4.3 on how bnodes are generated (if necessary).
 
------------------------------------------------------------------

5.3. Reification

I do not think this section is valid. AFAIK, RDFa does _not_ define reification at all!

------------------------------------------------------------------

6.2. FOAF

Section should be rewritten, because it reflects an outdated state. No bnode curies, (and bracketed curies), no <link> and <meta> statements in the body, etc.

I have a http://www.ivan-herman.net/foaf.html file that is written using (I believe) the latest status; this can be reused in the examples if needed...

------------------------------------------------------------------

7.3. Processing

At the start of the process, maybe it is worth specifying that [chaining] is set to false.

Part 1, establishing language: afaik, and that is reflected in the current XHTML+RDFa DTD, @lang is _not_ used. Either we should remove its reference or modify the DTD...

Part 2: isn't there a need for setting the [current resource]? Ie, if there is a @about attribute on [current element], then its value becomes [current resource]

Part 2, establishing [current object resource]: I think if there is only an @instanceof attribute, that by itself establishes a bnode as a current object resource. 

Part 2, it currently says "If none of these are present then a unique identifier or [bnode] is created.". I think the 'unique identifier' should be ommitted; this could be interpreted as the creation of a URIRef with some sort of a unique URI (like a uuid urn). I think the idea here is to generate a [bnode], that is it. Also, it says "final value of the [current object resource] is an absolute URI," which is not strictly true: it is either a URIRef based on an absolute URI or a blank node.

Part 3, second entry, @instanceof _if value not empty_ (at least that was my proposal, I think we more or less agreed on that)

_I am actually wondering whether the processing chapter should not be normative and most of the other chapters informative!_


Missing (?)
===========

- the previous draft included a number 'predefined' attribute names for metadata ('next', 'copyright', etc). Again, I am not sure this is an accepted resolution for the group, but my understanding was that those would be accepted by RDFa as if they were defined in the xhtml namespace. I think having those would make lots of sense

- I am not sure where we are with the rdf containers and collections. Is this still an open issue? I thought that what we have cleanly fit the rest of the processing model, so we could add it, too, somewhere.