[whatwg] RDFa
Henri Sivonen
hsivonen at iki.fi
Sun Aug 24 12:30:24 PDT 2008
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/
More information about the whatwg
mailing list