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

Re: Discussion with Ian and Henri about HTML5+RDFa (part 2/2)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 26 Jan 2009 16:09:01 +0200
Cc: Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Ian Hickson <ian@hixie.ch>
Message-Id: <9E832DFD-B483-473E-9DF1-3504E193AA18@iki.fi>
To: Ben Adida <ben@adida.net>

On Jan 26, 2009, at 03:55, Ben Adida wrote:

> And *most* importantly: the time for finding compromise on issues of  
> personal taste has come and gone.

In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015913.html 
  you said:
"Though I do think you should consider RDFa attributes in HTML5, I  
didn't mean to start this thread just yet (we're in the middle of our  
transition to Proposed Rec at W3C for RDFa in XHTML 1.1)."

When were you meaning to start that thread and how would your  
preferred thread starting time have related to the point in time after  
which the time for finding compromises would have been gone?  
Furthermore, I strongly disagree with the characterization of the over  
a decade-old text/html vs. XML DOM differences as an issue of personal  
taste.

> The idea of specifically *not* allowing follow-your-nose flies in  
> the face of much of W3C's work

If something turns out to be technically problematic on a large scale,  
the sunk cost of previous plans doesn't make it less technically  
problematic.

Please note, however, that the context of my remarks about following  
your nose was that I thought dereferencing something similar to a  
fixed profile URI in order to discover short name to URI mappings in a  
microformat-ish speculative idea (not RDFa) would be bad for the same  
reason that mostly constant DTD URIs are bad.

And people who publish XML documents are perfectly at liberty to  
change DTD URIs--just like people loading JS libraries from well-known  
CDNs are free to change script URIs. This is not so for URIs that also  
act as identifiers in addition to acting as follow-your-nose locators.

> and the recent TAG publication on the self-describing web.

I disagree with the TAG on some things.

> High load on a W3C web server (due to poor implementations) is not  
> evidence enough to undo a major design principle of web architecture.

I don't agree that 'follow your nose' is a major design principle of  
the architecture of the Web as the Web actually exists: None of the  
Web technologies that have been successfully deployed on the full  
scale of the Web embody the 'follow your nose' principle.

For example, naming of HTML elements, naming of CSS properties, naming  
of HTTP headers, naming of Unicode characters and naming of DOM  
methods don't follow the 'follow your nose' principle. (Note that even  
if Namespaces in XML counts as successfully deployed, it specifically  
treats URIs as mere opaque strings and doesn't say that clients should  
follow their nose and dereference namespace URIs.)

> The use case where someone copies and pastes partial HTML+RDFa from  
> someone's existing web site and gets upset doesn't ring true: the  
> same "problem" occurs in a much worse way with CSS, and no one seems  
> to be too upset about that.

With CSS, it is super-easy to assess the immediate effect of including  
CSS and whether you value the effects CSS gives you. (However, the  
problem of being guided to do something with no obvious immediate  
benefit does occur with CSS when someone tells someone else to convert  
a site from presentational HTML attributes to class+CSS or to rename  
all classes to be more "semantic".)

When someone instructs me to use e.g. CSS borders, even without any  
expertise, I can assess the practical effect of using CSS borders and  
whether the effect is worth the code complication to me. However, I  
have no way to tell if the source code maintenance complication of  
<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text 
" rel="dc:type">work</span> (copied and pasted from the  
creativecommons.org licensing tool) is actually useful for me in any  
way at all or if including it would just be participating in someone  
else's ritual. Interesting use of href and rel on a span, BTW.

> Removing CURIEs is not an option at this point,

If that's the case, I guess it's pointless for me to try to be  
proactive about coming up with a compromise.

> given the existing standard, the existing deployment (by folks  
> including Yahoo), backwards-incompatibility, and the lack of  
> evidence for needing such a change at this point.
>
> If we were only a few months into designing RDFa with no  
> implementations or deployments, this discussion would make sense,

Note that the difference in xmlns:foo DOM representation in text/html  
vs. application/xhtml+xml in *implementations* and *deployments* goes  
far further back in time than even the drafting of RDFa.

> as would some attempt at finding a compromise based on personal taste.
>
> But at this point, one has to present significant evidence of harm  
> to undo what otherwise seems to be working just fine.
>
> -Ben
>
> PS: Note that I do agree on DOM consistency, and I suspect @prefix  
> will fix that issue, as Manu mentioned. I've mentioned this to Henri  
> in prior conversations, I believe.

Is @prefix not an incompatible change to RDFa--especially if also  
applied to application/xhtml+xml for DOM Consistency? If that  
incompatible change is on the table, why would a more compatible  
approach of phasing out CURIEs by using xmlns:http="http:" in  
application/xhtml+xml during the transition be out of the question?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 26 January 2009 14:09:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 26 January 2009 14:09:47 GMT