- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 18 Sep 2009 21:01:56 -0700
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: HTMLWG WG <public-html@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>
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