[whatwg] RDFa

On Aug 24, 2008, at 00:15, Ben Adida wrote:

> Henri Sivonen wrote:
>> When you do so, please consider the HTML Design Principles from the  
>> W3C
>> side (particularly the one about DOM Consistency between HTML5 and  
>> XHTML5):
>> http://www.w3.org/TR/html-design-principles/#dom-consistency
>
> Sure. And since we're only adding attributes, I don't see how DOM
> consistency is going to be an issue.

The DOM consistency issue is that the xmlns attributes are DOM-wise  
different in text/html and application/xhtml+xml due to legacy  
reasons. The attribute that reads xmlns:cc="..." is represented  
differently in the DOM when the serialization was text/html than when  
it was application/xhtml+xml. We can't make xmlns:foo='...' conforming  
on HTML elements without either violating the DOM Consistency design  
principle (bad) or introducing namespace processing into HTML5 parsing  
(also bad).

>> The problem is that communities seldom resign to being happy on their
>> own. They often start propagating their happiness onto others, at  
>> which
>> point it would be better for the syntax for happiness not to be  
>> crufty
>> to begin with.
>
> I see you're resorting to subjective name calling. Not exactly  
> relevant
> to a technical discussion, nor do you have any proposals for "fixing"
> said cruftiness that wouldn't also fall short of the goal we've
> described in the ccREL paper.

Do you take the word "crufty" as name calling? Even though cruftiness  
is subjective, it's a legitimate consideration in language design. In  
fact, I think it's very important to avoid cruftiness in language  
design.

I did, from get-go, mention the possibility of using full URIs instead  
of CURIEs to avoid the prefix cruft (and to avoid the DOM Consistency  
problem). As for URIs necessarily being more crufty as identifiers  
than microformat-style short names, I think the problem isn't fixable  
in a solution that needs to be bidirectionally compatible with RDF in  
the *generic* case.

>>> That doesn't scale (unless you expect people to actually use GUIDs  
>>> with
>>> timestamps), and it's extremely web-unfriendly, since you can't  
>>> look up
>>> a concept to figure out what it might mean.
>>
>> It seems to scale for the Java community, and looking stuff up works.
>
> You mean, looking stuff up in your local CLASSPATH directory?

No, I meant typing names into Google. Looking stuff up works for  
people authoring Java code in the sense that searching for the fully- 
qualified name of a Java class that has public Javadocs works really  
well with Web search engines.

>> Adding Namespaces to HTML is much, much bigger a deal than adding a  
>> few
>> attributes in no namespace.
>
> It's not "Namespaces." It's "namespaces." And adding the ubiquitous
> computer-science concept of "namespaces" should not be a big deal at  
> all.

If it is tied to attributes whose name in the HTML tokenization stage  
start with "xmlns", it's either Namespaces or a violation of DOM  
Consistency between HTML5 and XHTML5.

>> The indirection
>> would still likely confuse authors as much as Namespaces confuse  
>> them.
>
> You keep switching your model. You want PDFs to be marked up, and you
> think authors will do that by hand and not be confused? No, right?

I'm not switching my model. I am saying several mutually compatible  
things, which perhaps makes my messages appear as incoherent.

My points are:

  1) Making RDFa in HTML5 *or* XHTML5 sensitive to xmlns:foo  
attributes is not HTML5-friendly, because those attributes are  
represented differently (as currently implemented and specified) in  
the DOM depending on whether the syntax was in text/html or  
application/xhtml+xml serialization.

  2) Metadata about a file travels best inside the file, and common  
Web formats have native facilities on the key-value level.

  3) The most common case of CC metadata fits the simple key-value  
case, and licensing is already too hard. Addressing the more complex  
cases by making the common case complex seems like a bad idea to me.

  4) Considering #2 and #3, I don't find ccREL a convincing case for  
justifying the inclusion of RDF data in HTML5 (although there might be  
other cases).

  5) I think URIs (directly or through indirection) are more clumsy as  
identifiers than short names. Since RDF vocabularies use URIs as  
identifiers, I find creating more microformats (even if they need more  
one-off speccing) a more appealing way forward from the language usage  
point of view than importing RDF vocabularies in a generically  
mappable way. (I can't see how generic mapping can be had without  
using URIs as identifiers.)

  6) I think indirection via prefixes is bad, because experience with  
Namespaces in XML shows that it confused people a lot. Both full URIs  
and short prefixed names where the fixed prefix doesn't expand into  
anything are better.

  7) For collision avoidance, Java-style naming works equally well as  
using URIs, but Java-style names don't confuse people into  
dereferencing them as addresses.

  8) Using URIs (full URIs without indirection) as class and rel  
values is already allowed in HTML5, so putting RDF property URIs in  
those existing extension points routes around the process for adding  
new stuff to HTML5 syntax.

>> Also, I gather that the videos are captured with something like Snapz
>> Pro X--not exported directly from Keynote. The "tools will save us"
>> vision
>
> You're putting words in my mouth. I didn't say "the tools will save  
> us."
> I said "the tools will help us, but they're not required."

"Tools will save us" is a common expression for referring to a certain  
sentiment. It's not a direct quote.

> And again you're making a point that, in some cases, the tools won't  
> be
> 100% helpful. So what? We should refuse to adopt a solution because it
> won't solve *all* of our problems?

No, we should refuse a mechanism that can reasonably be expected to  
have a relatively high failure probability. As the toolchain becomes  
longer, the probability of failure increases, since it takes only one  
tool in the chain to fail for the whole chain to fail.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 24 August 2008 12:30:24 UTC