Re: Updated Editor's Draft available

Hi Ivan,

Great...thanks for the very useful comments, and for turning them
around so quickly.

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

That's an interesting point. Shane asked me yesterday whether that
section should be normative or not, and I said that I couldn't see how
we could make it normative, since it used the idea of recursing
through a DOM; since I thought we should be able to support other
processing models it felt wrong to restrict things.

But I guess with a little work we could resolve that, perhaps using
some less specific language.


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

Ah...I never knew there was a 'house style'. :) We'll use that from now on.


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

We still need compact URIs in @rel, @rev, @instanceof and @property, though.

So far, we've agreed that the QNames syntax is incorrect, and also
that we're going to use CURIEs to give us compact URIs. However, due
to some people feeling uncomfortable with a a direct link to the CURIE
spec itself, we've agreed to simply lift the prose and syntax from
there. This gives us a little flexibility, and makes it not much
different to recent SPARQL drafts (which now have EBNF for something
exactly like CURIEs).

Of course, this means that there will be two specs that are referring
to something that is exactly the same, and you never know, people
might decide that referring to the CURIEs spec is not so bad after
all.

But a bridge for another day...


I've not had a chance to go through the rest of the document--I've
been working solely on the processing model section--but I'll do so
tomorrow morning, before the telecon. When I do I'll incorporate the
changes that you suggest below. I've added some comments inline.


> ------------------------------------------------------------------
>
> 3.1 Overview
>
> The @instanceof is missing from the list at the start

Thanks.


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

Yes, I think there might be a few of these to tidy up.


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

That's a very old sentence. :)


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

Let's hope the suffering is over...bring me your huddled masses, and
all that. ;)

The funny thing is that RDFa was *always* intended to be independent
of language. Early drafts were incorporated into the XHTML 2
specification, and as you'd expect, the wording changed to make it
XHTML 2 specific. I think what happened here is that newer drafts of
the syntax document took as their starting-point an XHTML 2-specific
draft rather than a pre-XHTML 2 draft.

Anyway, I'll try to remove anything like that before tomorrow's call.


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

Well spotted.


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

Yes.


> ------------------------------------------------------------------
>
> 3.3. Relating document components
>
> Again the "RDFa allows a single XML dialect document to include multiple RDF entities" term
> with 'XML dialect'...

Not sure what's happening there, but I'll sort it out.


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

Yes, sorry about this. It's why Shane said to take the processing
model section as the most up-to-date, because we know that there are
still parts of the main body of the document that are either no longer
necessary or haven't yet been edited.


> ------------------------------------------------------------------
>
> 4.1. Processing
>
> @instanceof is missing from the list

Thanks.


> ------------------------------------------------------------------
>
> 4.2. Compact URIs
>
> Just making a note again on the bracketed CURIE

There shouldn't be any bracketed CURIEs, just 'basic' ones.


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

Right.


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

I'll be honest, that's what I was really hoping to hear! If everyone
is happy with the section 7 approach, then I would *much* prefer to
use it. I don't really like the idea of describing things in terms of
'looking for ancestors', and all that. And I also don't like the 'if
this, then that' descriptions that we have used up until now, because
it's very easy to miss things when implementing, and it's also quite
difficult to explain.


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

Right.


> ------------------------------------------------------------------
>
> 4.3.1. The about attribute
>
> The literal for Mark should be plain and not XMLLiteral (in the example)

Yes.


> ------------------------------------------------------------------
>
> 4.5.1. Literal object resolution using the content attribute
>
> the text between the two example refer to XMLLiteral. It should not.

Yes.


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

Yes.


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

Right.


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

Yes.

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

Yes.


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

Yes.

Apologies again that you've had to waste time reviewing material that
shouldn't even be there...as I said above, these 'stray' sections
should have been removed, and that is why Shane made the point about
'the processing model is the most up-to-date'.


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

Yes, good idea. I actually use your page to test my processor. :)


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

Right.


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

Ok.


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

That's in step 1, where we do anything that can change the evaluation
context. Part 2 is all about working out what objects you have.


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

You're right, and I'm assuming that processors will make all sorts of
optimisations to the steps I've outlined. But the approach I have
taken is that regardless of the attributes on an element, you will
always 'calculate' an object resource, even if you don't end up using
it.

So the object resource on an element with @resource, @src or @href is
the value of the attribute. And if none of those are present, the
value is a bnode.

As I say, whether the processor uses that value is another matter, and
that's where implementers may choose to add some optimisations. But if
there is an @instanceof attribute, then the object resource is used to
create an rdf:type, and if there is a @rel or @rev present it is used
to create a normal triple.

If a triple is created then our chaining kicks in, which means nothing
more than saying that the object resource becomes the new 'subject'
for any nested statements (i.e., it becomes the current resource for
the evaluation context).

My view is that this way of explaining it makes it much easier to
define chaining as simply being caused by @rel, @rev, and @instanceof.
In our previous explanations we had to say that it was @href,
@resource and @src that caused chaining...but additionally if none of
those attributes were present, then you still might get chaining if
@rel, @rev or @instanceof were present! A lot of if's and but's.


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

Ok, I'll sort that out.

I was actually going to go the other way, though, and avoid mentioning
bnodes. All we're really concerned with is creating a unique
identifier, and we can then provide rules on how that should be done.
I added "[bnode]" at the last minute just so that you guys knew what
it was all about. :)


> 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 don't recall a discussion on that, although I do remember you
raising the idea on the list. I'll try to find the thread when I work
on this tomorrow, but if you have a reference that would be
appreciated.


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

Yes, you're right. There are a couple of ways that this could be
handled, and I'll work on that.


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

I think they are easily introduced into the third processing step if
we decide that they should be in. I thought the status was that they
would be left until we have this version out of the way. In the
description I've tried to allow a little room for processors to do
more processing than is defined here, without being non-conformant.

Thanks again for turning your comments around so quickly Ivan...I'll
try to do the same with the next round.

Regards,

Mark


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Wednesday, 5 September 2007 12:16:18 UTC