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

Mark,

I am going through my piled-up-mail (oh joys of travelling!) and I found
your mail related to @rel and usage of rel=":next"

HTTP://www.w3.org/mid/a707f8300710180339m29c20472t803e826a735b1bc0@mail.gmail.com

I think I understand the core part of the argument, and I think I agree.
It is actually in line with DCMI's intention to propose the 'proper'
usage of RDFa (instead of the "dc.title" style) once RDFa is a rec...

Ivan



Ivan Herman wrote:
> 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