W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2008

Re: Comments on the latest version of the syntax document

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 24 Jan 2008 12:30:36 +0000
Message-ID: <a707f8300801240430y6bed96c8q5b69f916aacb0b99@mail.gmail.com>
To: "Ivan Herman" <ivan@w3.org>
Cc: "Shane McCarron" <shane@aptest.com>, "Ben Adida" <ben@adida.net>, "W3C RDFa task force" <public-rdf-in-xhtml-tf@w3.org>

Hi Ivan,

> here are my comments on the latest version[1].

Many thanks...very useful comments.


> - Section 2 lists the namespace prefixes for 'svg' and 'xh11'. But these
> are not used in any of the examples, as I could see.

Well spotted...they are no more.

(I think very old drafts showed RDFa being used in other languages.)


> [...]


> - Section 3.6.: The text says "There is one small change that we make to
> N-Triples, which is to allow long URIs to be abbreviated by using a URI
> mapping. This is indicated by expressing a compact URI as follows:"
>
> We may think of making use of the fact that Turtle has now (since about
> 10 days:-) a stable, W3C URI:
>
> [...]
>
> http://www.w3.org/TeamSubmission/turtle/
>
> and the document is now under W3C copyright. We could, therefore, refer
> to Turtle in the list of possible serialization at the beginning of the
> section, get rid of this 'small change that we make...' text, and simply
> say that we use Turtle syntax in our examples.

Excellent point...done.

I've also modified the examples in section 3.6 to include the @prefix
declaration.

In passing, I would say to Manu and Shane in relation to their
opposition to using ":foo" that this is a common construct in Turtle.
By retaining it in RDFa/CURIEs you'll see that CURIEs almost exactly
mirror Turtle's prefix and abbreviation mechanism, and I think this
consistency makes thing that little bit easier for people coming at
RDFa from the RDF world. (And those coming from the HTML world can
ignore it if they like.)


> B.t.w., the reference list [N3-PRIMER], too, but it is not used in the
> text. It is probably better to remove it (and add a Turtle reference...)

Done.


> - Section 3.8: I would not refer to QNAMES at all. We use CURIES, that
> is what they are, and that is it. Don't open the door for discussions:-)

Ok. You know I'm not going to argue with that! :) It's interesting
that Turtle now no longer refers to QNames, and nor does SPARQL. Is it
possible that CURIEs was not as mad an idea as everyone said...... ;)

Anyway...done.


> - Section 4.1: I am not sure I understand the 'Merge namespaces' issue
> listed there, mainly in line with the latest description of the
> @rel="next" value. Isn't that issue (if there was ever any) moot?

I'm saying that we currently have two URIs kicking around, one for the
@profile attribute, and one for the XHTML vocabulary. My suggestion is
that we don't need both. First, using a 'namespace' in @profile is
counter to normal XHTML usage, so I just don't like that, anyway. I
recognise that people want a value in @profile to indicate that 'this
document contains RDFa', but that shouldn't be done at the expense of
proper use of @profile.

I recognise, too, that some people want a value in @profile so that
they can run a GRDDL transform. I did point out in other emails that
GRDDL supports a number of mechanisms for hooking in a transform, and
@profile is only one of them.

Anyway, my feeling is that if the document referred to by the URL used
in @profile contained a definition of the new @rel/@rev values in
XHTML+RDFa, then it would become a 'proper' use of @profile. It could
of course also include the hook to GRDDL, and that would satisfy my
desire to see us remain as consistent with 'ordinary' XHTML as
possible.

But if we did that, surely we'd put those definitions into the
document at "...vocab#", rather than in some RDFa namespace document?
After all, what is the namespace document for anyway, since all of the
new attributes belong to XHTML?

So that's my argument... :)


> - This is just a small remark, not really on the document but on one of
> the semi-pending issue. The current text says:
>
> [[[
> The [current subject]. The initial value will be the same as the initial
> value of base, but it will usually change during the course of processing.
> ]]]
>
> This, in fact, is indeed equivalent to the fact that the <html> element
> has an implicit @about="" attribute set. (I note that because there was
> a slight uncertainty about that in some of the discussion mails...)

Yes...I actually need to add more to this for other reasons too. I
don't know if you saw my post the other day, but I realised that even
if the URL for the document is:

  <http://www.w3.org/People/Ivan#me>

the *base URI* is actually:

  <http://www.w3.org/People/Ivan>

since 'absolute URIs' don't have fragment identifiers. I'm using the
terminology from RFC 3986 very precisely, here, and since the meaning
of 'absolute URI' runs slightly counter to what one might think it
means in common parlance, I've removed all references to it from the
document, and replaced it with 'full URI'.


> - Again a comment on the angels and the pin in 5.4. The text says (after
> the fist example): "In RDFa these mappings are expressed using XML
> namespaces". The issue is that we do _not_ use XML namespaces, but just
> the XML namespace _syntax_. May be better to state that correctly...:-).
> Same remark in 5.4.1. referring to "XML namespace mechanism".

Good point...done.


> - In 5.4.3 the references to the CURIE Syntax Definition are all
> referring to the document itself, instead of the relevant chapter.

Thanks...done.


> - It is very good to have Section 6. However: is it o.k. to mark that as
> 'normative'? My feeling is that the 'normative' part is the processing
> step description and Section 6 is a (necessary!) informative section.

Mmm...that's a good point. It would probably be better to keep all the
normative stuff in one section; I know from other specs that if the
definition is spread over too many sections then contradictions can be
introduced. I won't touch anything though, until we hear Shane and
Steven's views.


> - Section 7, commenting on the angels again:-). I think the case of "_:"
> should be explicitly defined, it is a little bit open to interpretation.
> With the current text I might agree after all that all of them refer to
> the same BNode (sigh...), but making it explicit would help.

Ok. I'll look at that a bit more.


> - The text in 9.2.6 says:
>
> [[[
> This attribute describes the relationship between the resource specified
> by @about (or its default value) and the resource referred to by @href
> as defined in XHTML.
> ]]]
>
> As we all know, in the case of RDFa, this is a bit more complex than
> that...:-) I think no text should appear here, and it should refer back
> to the relevant section.

I agree...but then I also agree with your next point.


> Actually: I wonder whether section 9 should be part of the document _at
> all_. It does not add _any_ new information for @about and the others,
> apart from our issue on the predefined list of @rel/@rev. In my view,
> the whole section could be collapsed to the list of reserved words only
> (if, after all, the group decides to keep the list as part of the RDFa
> document, instead of having it separated in a namespace document).

I agree with this, and have for a while now felt that we're storing up
trouble here. At the beginning of the document we say 'For a normative
definition of these attributes see the XHTML Metainformation
Attributes Module'. That would be fine if all we were doing in section
9 was clarifying the format of values. But since there are many
mentions to things like what the attributes 'do', I think it will lead
to confusion.

I'll wait to hear what Shane says before doing anything, since he has
done the work on this part.

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 Thursday, 24 January 2008 12:30:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2008 12:30:59 GMT