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

Dan Brickley wrote:
>> embedding semantics in HTML, and to at least one important web design
>> principle.
> 
> Which one? (a link into webarch spec would help here)

follow-your-nose, the self-describing web, and the benefits of URIs

http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
http://www.w3.org/TR/webarch/#uri-benefits

(in response to the use of "foo-bar" to actively *prevent* de-referencing.)

> HTML5 is still a moving target, so there is inevitably some wiggle-room
> there as we define how (if at all) the RDFa work makes sense in that
> context.

Sure, but RDFa is not a moving target anymore, and we are on the RDFa
mailing list :) HTML5 adopting a backwards-incompatible version of RDFa
is something I strongly oppose. That was the focus of my email.

> BTW what you dismiss as 'personal taste' is what some in the
> WHATWG/HTML5 scene consider to be 'editorial judgement'. Can you find
> language for continuing this conversation that sets that distinction
> aside for now?

I'd rather we not try to sugar-coat what is, in truth, personal
preference. I didn't mean it as a bad thing. My sense of taste certainly
had an impact (though thankfully not too much) on RDFa. I just mean that
there is a time for personal preference, and a time when that can't
matter anymore on its own.

Once HTML5 is finished, I'm sure many will find certain aspects
distasteful. But unless there are serious practical problems as
supported by evidence, the value of the standard will trump personal
taste (or 'editorial judgment') at that point.

> Henri clarified this point in response to Manu:

[...]

> Henri: "(To be precise, this is more of an issue with the XML DTDs than
> the HTML ones, because there are actual DTD-loading XML parsers out
> there.)  It isn't only about the ability of the vocabulary server to
> serve a lot of data. It's a problem when communication between two
> parties on the network is reliant on a third party keeping a service
> running."

Then it sounds like there isn't a problem if we issue implementation
guidelines for existing RDFa, I believe? De-referencing the namespaces
is unnecessary for RDFa parsing.

I appreciate Henri's argument regarding de-referencing bundles of
default keywords (which is not part of RDFa so far), and I agree it will
be good to consider this issue thoroughly. I don't think it's a
showstopper, but it is certainly worth considering.

> On the follow-your-nose aspect, the proposal/profile I was exploring
> with Henri, and which his http://validator.nu/ tool now checks, doesn't
> abandon this idea. It just avoids shortcutting of URIs into short part /
> long part pairs.

And it is my opinion that, if this introduces a backwards-incompatible
change, then it's a non-starter. If you're exploring a way to hack a
backwards-compatible approach, then that is certainly interesting and I
have no issue with it at all. I might even use the hack :)

> (Yup. Also digitally signing namespace documents provides some modest
> insurance against domain name loss / compromise. This (signing) theme is
> getting some attention via the widgets/webapps effort, it's worth
> keeping an eye on that.)

That sounds very cool.

> That's great. When I talked with Ian he was asking how many RDFa use
> cases were in the 'copy and paste something I don't understand' area
> (akin to .js widgets), versus copy/paste but edit and tweak, vs hand
> author etc. It is very good to have implementor feedback. Have you done
> any statistics to see what proportion of CC RDFa is still a sensible RDF
> graph, how often it is customised/tweaked and so on?

We have not done those statistics, in large part because we didn't have
a good way to do web-wide scanning of RDFa markup, although it's now
becoming a possibility with Yahoo SearchMonkey. I'm hoping we find the
time to do this. We do have a significant amount of anecdotal
information from our community.

> Well at the moment, neither CURIEs nor RDFa work in HTML5.

It may be that you and I see things very differently here: RDFa in HTML5
cannot differ in backwards-incompatible ways from RDFa in XHTML,
otherwise it significantly dilutes our effort. Creative Commons needs to
push out *one* chunk of HTML, not one for every version of HTML. And I'm
pretty sure Yahoo doesn't want to parse things differently depending on
the HTML version (which is not always clear cut.)

That's why we're interested in @prefix, which would be enabled in *all*
versions of HTML. (And xmlns would continue to be supported in RDFa in
XHTML.) Then, all existing RDFa still works, and all new RDFa that wants
to be compatible with HTML5 and XHTML would likely migrate to using @prefix.

But as Mark pointed out, that portion is by no means frozen, since it's
not part of the existing REC. I didn't mean to imply that @prefix was
beyond the discussion phase.

> A no-namespaces / no-CURIEs profile of RDFa *does* work in XHTML+RDFa
> today, and this imho is reasonable: nobody can force me to use
> abbrevations for URIs when I want to use URIs directly. However I need
> to use the xmlns:http="http" hack right now. I'd like to have a better
> sense for why this can't be made to go away.

I disagree with "nobody can force me to use abbreviations." Design
decisions sometimes require compromises. CURIE support was one of the
more important design principles we agreed upon after years of
discussion and public input. So in fact, you do need to use
abbreviations right now, and it almost certainly reduces the amount of
markup you write (e.g. how often do you only use *one* FOAF URI in your
RDF?)

I'm happy to explore the hack you're pointing out if it's backwards
compatible.

> I share your frustration, but I think it is worth exploring a compromise
> subset, at least as an awkward starting point.

As long as it doesn't break backwards compatibility.

> XHTML+RDFa can continue to work fine.
> 
> We're talking about HTML5+RDFa here, which right now is not working fine
> as a carrier for the kind of rich, structured, URI-disambiguated
> metadata we care about in RDFa circles.

But it can't work in a backwards incompatible way. That dilutes the
existing work and makes life unnecessarily complicated for everyone
who's already invested time, effort, and code into this.

> IMHO the best way of fixing this situation is to explore common ground,
> and once we've identified some (my candidate: RDFa with long-form URIs
> instead of abbreviations), explore the costs and benefits of variations
> on that theme in terms of evidence.

I disagree with this approach, much as I'm sure the HTML5 group would
disagree about reevaluating the decisions it has made (with public
input) once HTML5 has gone final. There's overwhelming value in
established standards, especially when companies as big as Yahoo have
invested their time and effort into the technology.

I certainly understand and appreciate one important difference: RDFa is
being considered for inclusion within HTML5, so we're not talking about
independent standards. But Shelley's point is right on: when SVG was
being considered for inclusion, it was about including it or not. There
wasn't much talk of redesigning SVG itself.

That's not to say that *nothing* will be done to make RDFa HTML5
friendly. Henri's point about DOM consistency and not using XMLNS is one
that I think we can make work with backwards compatibility, and so we're
doing just that.

However, in my opinion, the default approach of the HTML5 group, if it
is indeed attempting to integrate rather than reinvent, should be "how
can we include this wholesale" first, and then if there are intractable
problems, explore backwards-compatible ways of addressing them.

The evidence presented against CURIEs so far falls short of intractable
problems.

> And of course, Creative Commons are a major end-user
> too. Your observations are those of a group serving real needs; RDFa at
> CC is not a hammer looking for a nail. I hope to hear some
> acknowledgement of that from a few more HTML5 enthusiasts sometime.

That would go a long way towards reducing a growing feeling in the CC
community that the HTML5 group has a Not-Invented-Here problem.

-Ben

Received on Monday, 26 January 2009 19:05:57 UTC