Re: rdfa-syntax First Public Working Draft is up!

Hello Mark,

Mark Birbeck wrote:
> Hi Ivan,
> 
> I think your list is fine, but just in case you weren't aware, we did
> agree that some things were more important than others to get into the
> first draft, so some things were consciously left out for now.
> 

That is fine! I think getting the document out was of the highest
priority and, as I said, all these issues were more the edge cases. I am
really happy the document is published...:-)

> 
>> - get the @instanceof situation to an equilibrium point and, possibly,
>> adapt the wording of the processing model
> 
> There will need to be minor changes to the processing model, and there
> will need to also be changes to section 6.2.2.
> 

Yeah. I hold off changing on my implementation to see the result of the
test case discussions and the processing model changes. Can you send me
the proposed changes as soon as you have them? Putting them into pyRdfa
should be a breeze, it just a matter of knowing what to do...

> 
>> - the RDFa profile is not mentioned in the document; it should be part
>> of the conformance clause. We should decide whether the presence of the
>> profile should be mandatory or just optional (but advised).
> 
> As we said in another thread, we have agreed that an RDFa value in
> @profile. I guess we could 'advise' its use in certain use-cases, but
> the problem with that is nailing down just what conditions that should
> be. The reason the value is optional is that there are plenty of
> use-cases where it will either not be provided, or it *cannot* be
> provided. In the latter situation I don't think it makes sense to
> 'advise' using a @profile value if it's simply not possible to provide
> one.
> 

Hm. Which use cases are you thinking about? In all cases documented in

http://www.w3.org/TR/xhtml-rdfa-scenarios/

the usage of @profile seems to be quite all right, I am not sure where
you thing @profile _cannot_ be provided.

This is a long standing discussion, in fact. The usual question is: in
the absence of a @profile, how would a client know that it is RDFa? _If_
clients use the XHTML+RDFa DTD than maybe that could be used although
the fact is that most of the clients ignore that. Note, for example,
TimBL's comments on a similar issue (though related to microformats):

[[[
...missing a DOCTYPE does little or no damage, as (modulo tag soup
issues) the DOCTYE is a link in the chain of reasoning about what the
document means. The HTML profile for microformats is however a crucial link.

...

One danger is that, because tools such as browser plugins support
microformats without checking for a profile, then those tools will
erroneously pick up data from pages which use classes for a completely
unrelated purpose. This attributes to the author information which they
never meant to give.
]]] http://microformats.org/wiki?title=misconceptions&diff=21835&oldid=21828

I am sure we _will_ have HTML files around (1) not using the DTD because
they will not even be XHTML and (2) using RDFa attributes. I remember
when I announced pyRdfa on one of the mailing lists (or in my blog, I do
not remember), one of the answers was that it would be good to have an
RDFa parser for tag soup HTML, too. For those, Tim's comment still
applies: @profile does give you an extra mechanism to follow your nose.
I still believe it would be strongly advised to use it (bar of making it
compulsory...)

Ie, I wonder whether this issue is really so clearly settled.

> 
>> The profile
>> document itself should also be done, probably by referring to Fabien's
>> XSLT script so that GRDDL processors could automatically handle RDFa
>> files, too.
> 
> I'm not that up to speed on GRDDL. Do you know how to do all of this,
> and define it? (I don't mind working it out, but if you already know
> it would obviously be quicker.)
> 

Well... in fact, Fabien has already done it in:

http://ns.inria.fr/grddl/rdfa/

and announced it in:

http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0121.html

I think it would be cleaner (sorry Fabien!;-) if the mechanism was
copied to the official, W3C profile document, referring to the same
script. Ie, the profile document should include:

<head profile="http://www.w3.org/2003/g/data-view">
    <link rel="transformation"
href="http://www.w3.org/2003/g/glean-profile" />
...
...
</head>
<body>
....
<a rel="profileTransformation"
href="http://ns.inria.fr/grddl/rdfa/2007/09/19/RDFa2RDFXML.xsl">http://ns.inria.fr/grddl/rdfa/2007/09/19/RDFa2RDFXML.xsl</a>

</body>

(we can also choose, _eventually, when RDFa is done_ to install Fabien's
script on the W3C site if he agrees; these are all details)


> 
>> - whether the literal canonicalization also applies to XML Literals, or
>> whether those should be copied to the output verbatim
> 
> Yes...tricky. That is one issue that I don't recall us _ever_ having a
> discussion about, so if anyone has strong views on either approach it
> would be good to make them known now.
> 

Well... my issue is whether we have the right to modify the author's
formatting. He/she may want to reuse the result somewhere else via RDF,
and the exact formatting might have a semantic value, so to say. The
obvious example is if the content includes a <pre> tag. That is why I
would be in favour of leaving it verbatim in the output.

> 
>> - the current document still lists a set of predefined values for
>> @property; if I am not mistaken the group has decided that we would not
>> have those. This is important because it affects the @rel/@property
>> values without qualified names. Are there still open issues with those?
> 
> You are right that we have agreed to move the @property values to a
> common list, so there is no longer a distinction between @rel, @rev,
> @property, etc. However, the actual approach to @rel and @rev hasn't
> yet been finalised. The last 'proposal' is, I believe, my suggestion
> that we should encourage authors of 'new' mark-up to use this syntax:
> 
>   <link rel=":next" href="..." />
> 
> This would make use of the default prefix, which we can easily
> hard-wire to "http://www.w3.org...vocab#", by changing this section:
> 
>   <http://www.w3.org/TR/rdfa-syntax/#s_curies>
> 
> This would have the effect of saving authors from needing to declare
> the XHTML namespace, i.e., from having to do long-winded mark-up like
> the following:
> 
>   <html
>    xmlns="http://www.w3.org/1999/xhtml"
>    xmlns:xh="http://www.w3.org/1999/xhtml/vocab#"
>   >
>     <head>
>       <link rel="xh:next" href="..." />
>       .
>       .
>       .
> 
> Since this then gives us a way to use the XHTML vocab values, we can
> simply say that CURIEs that have no prefix, or don't use the 'default
> prefix', are simply ignored in this version of RDFa in XHTML. That
> gives us time to think about how we might deal with both the XHTML
> values, and other values such as Dublin Core.
> 
> Note that Ben has indicated he is happy with this suggestion--perhaps
> others could also chime in on whether they think it is acceptable or
> not.

Hm. I am not sure I understand the reasoning, I must admit. _If_ the
syntax document describes this change in terms of changing the DOM by

- adding the xmlns:xh="http://www.w3.org/1999/xhtml/vocab#" to the head
- adding the "xh:" prefix to each prefix-less value

then the author is under no obligation of adding the namespace
himself/herself.

Even if we do not choose the term 'preprocessing', I think it can be
explained in the syntax document.

(That put aside, RDFa _does_ force authors to add namespaces anyway...)

Having said that: as far as I am concerned, it can go either way, I do
not feel very much bound to anything. It just has to be finalized:-)

> 
> 
>> I have the impression that the only thorny issue is the @instanceof.
> 
> And the @rel one just mentioned. :)
> 

If this is our biggest thorn, I am happy;-)

> On @instanceof, I think it is mainly myself and Ben who are still
> fine-tuning our views on this. :) We have set a target of trying to
> thrash this out next week, when he returns from holiday.
> 
> 
>> A different issue is whether we want to give some more formal status to
>> the hGRDDL line of thought (I have some major issues with that one, I
>> must admit...). We may decide not to add this to the current round of
>> RDFa, though.
> 
> Right...although I think the way out of this is to use the ":next"
> syntax, and then punt the _entire_ question of legacy values to a
> future version, or to hGRDDL, or whatever. But provided we give
> authors a way to use things like
> "http://www.w3.org/1999/xhtml/vocab#license" then we don't need to say
> _anything_ about hGRDDL or pre-processing or anything else, at this
> point. To be clear, the way that authors would get access to
> xh:license, and friends, would be like this:
> 
>   <a rel=":license" href="http://creativecommons.org...">license</a>
> 

Mark, I do not follow you on that:-(

Cheers

ivan

> 
>> Anything I forgot from my list?
> 
> I think it's good. :)
> 
> Regards,
> 
> Mark
> 

-- 

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