Re: The Complexity Argument (was: Re: Request to publish HTML+RDFa (draft 3) as FPWD)

On Fri, Sep 18, 2009 at 2:19 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> RDFa is more complex than Microformats and Microdata. It is more complex
> because the set of use cases are more complex. Follow-your-nose,
> vocabulary validation, data typing, and inferencing are just a few of
> the design goals for RDFa, based on the requirements in the use cases.

I think this gets to the heart of the issue. I don't think that RDFa
is more complex because the people designing it didn't value
simplicity, but because it has aimed to solve more complex use cases.

> To look at this another way, one could claim that HTML5, Javascript,
> canvas, or SVG is too complex for regular web authors. Those
> technologies are certainly far more complex than RDFa, yet we see
> widespread use of each of those technologies on the web.

I *certainly* think that HTML has many aspects that are much more
complex than I would like. Much more complex than they would be if we
had the luxury of designing this thing from scratch. Just look at how
prevalent XSS and CSRF security problems are on the web and it's clear
that HTML is too complex.

Unfortunately we aren't designing HTML from scratch. We're bound by a
desire to be backwards compatible with the billions of web pages that
users are using today.

While HTML started simple, it has gotten a lot more complex over time.
For a variety of reasons.

> If you think RDFa is too complex, please propose an alternative or
> propose alternatives to the way RDFa works that are backwards compatible
> with XHTML+RDFa 1.0. We have some fairly large field deployments of RDFa
> and the number is growing, not shrinking. We need to be very careful to
> support these early adopters while making things simpler, if possible.

This is why I said that I don't think some of my comments were
possible to address. If the goal is to be compatible with XHTML+RDFa
then I don't think it's possible to reduce the complexity
meaningfully.

> There are trade-offs by going simpler, if there were no tradeoffs, we'd
> have made those changes a long time ago. So, if there is a
> simplification that you can see that doesn't result in a big tradeoff
> and is backwards-compatible with most of XHTML+RDFa 1.0, we'd be glad to
> go that route if it results in a simpler system.
>
> To do that, however, we need a concrete proposal.

I personally think that microdata is a better proposal. I do realize
that it doesn't satisfy many of your goals, but I don't share all of
those goals.

>> While processing using DOM Level 1 methods is seems doable, it is the
>> only specification that I know of where that is done. I would imagine
>> that this will cause problems. For example a javascript implementation
>> couldn't use the lookupNamespacePrefix function defined in DOM Level 3
>> and implemented in most commonly used browsers.
>
> Could you elaborate more on this point? Specifically, are you saying
> that most Javascript implementations wouldn't be able to implement RDFa?
> Or are you saying technologies that only provide DOM Level 3 wouldn't be
> able to implement RDFa? Or are you saying something else?

I'm saying that a Javascript implementation will have a harder time to
use RDFa. Or an implementation that uses any output from a conforming
HTML parser.

As stated in a previous email in the last thread, this is because markup like:

<div xmlns:foo="http://www.example.org/myNamespace">

does not create an attribute in the "http://www.w3.org/2000/xmlns/"
namespace. It creates an attribute in the null namespace (or, if i
recall correctly, the correct language is that it's not in a namespace
at all).

(For what it's worth, I think the fact that we're having this
discussion is a sign that namespace declaration is too complex).

/ Jonas

Received on Saturday, 19 September 2009 04:02:57 UTC