W3C home > Mailing lists > Public > www-tag@w3.org > March 2008

Re: Reviewing Last Call RDFa

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 24 Mar 2008 18:19:13 -0400
Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>, olivier Thereaux <ot@w3.org>, Dan Connolly <connolly@w3.org>, TAG List <www-tag@w3.org>
Message-Id: <BB230CA7-3A63-4766-B733-1094D9420611@w3.org>
To: Ben Adida <ben@adida.net>


On 2008-03 -21, at 18:17, Ben Adida wrote:

>
> Hi Tim,
>
> Thanks for your comments on this, your time is much appreciated!
>
> I'll address only the items that are uncontroversial from our point  
> of view, leaving the remaining issues to a more detailed discussion  
> with the whole group.
>

So the others are even more controversial? ;-)

>> ** Deployment path and architecture:
>> In general, is the deployment path for this spec that (a) it  
>> introduce new attributes into the HTML namespace, and that  
>> conforming RDF-aware HTML clients be expected in future to  
>> understand RDFa, or is it that the GRDDL transform link from (b)  
>> the document or from (c) the HTML schema?
>
> The original goal was (and still is) to introduce new attributes in  
> the namespace / schema of XHTML2, XHTML1.1+RDFa, and eventually (not  
> in this spec) HTML5 once it specifies a mechanism for schema  
> extension a-la XHTML modularization.

It seems the mechanism is simply that the relevant attributes get  
defined in some spec and everyone implements them or ignores them. In  
the case of RDFa the situation is easier than some, as the browsers  
which don't understand them will ignore them to no ill effect.

You have to negotiate with the HTML working group, but by not using  
namespaces, they put themselves in the position of having to accept  
contributions from those who wish to extend the language, it seems to  
me.

> However, we have received many comments asking us to "please include  
> a @profile" because folks wanted to stick with GRDDL as their  
> processing approach. We believe GRDDL is not the ideal technology  
> for parsing RDFa, since GRDDL loses the DOM <-> RDF correspondence  
> which is quite important when a human wants to extract structured  
> data from a visually rendered web page. However, GRDDL is better  
> than nothing. Thus, we encourage authors who *can* to add a  
> @profile, but we don't make it mandatory, because the normative path  
> to discovering the RDFa flag is the schema / DOCTYPE (more on DTD in  
> response to your other comment below.)
>
>> Is the purpose of the profile to allow GRDDL engines to find RDFA,  
>> or to protect against a non-RDFa document being interpreted as an  
>> RDFa one,
>
> The former: to help GRDDL folks.

Ah.    Help the GRDDL-aware readers, presumably.  In that case all  
writers must include the profile.  Unless you divide the world into  
two sets, the GRRDL-aware who exchange one set of files and the non- 
aware who exchange a separate set of files. In that case, you have two  
languages, one xHTML+GRDDL and the other xHTML+RDFa.  If you have one  
language, then you have to have common expectations about whether it  
needs the profile or not.

If you are going for RDFa being in HTML, then you more or less expect  
GRDDL clients to apply the RDFa transform to anything HTML even  
without a profile.

Why not put the GRDDL pointer in the xHTML namespace document?   I  
thought that GRDDL


>> 4.1   "There SHOULD be a DOCTYPE declaration in the document prior  
>> to the root element."  DTDs are a an obsolete technology. Suggest  
>> the spec not refer to them in any way.
>
> We would be happy to do so.... if only there was a W3C REC (and a  
> validator.w3.org implementation) for validating XHTML1.1 using XML  
> schema. Sadly, there isn't, and since we get a lot of "this won't  
> validate!" criticism, we had to go with DOCTYPE and DTDs.
>

The validator is a piece of code which W3C runs as a service.  It is a  
service to support the specs, not the other way around!  Sometimes we  
get things back to front in this world.
I have been on a crusade for  while to make the validator accept  
extensions in general as that is how HTML and XML work (in different  
ways).  I have been discussing this with Olivier.

Tim

> -Ben
Received on Monday, 24 March 2008 22:19:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:53 GMT