W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2009

Re: Publishing a new draft (HTML5+RDFa)

From: Michael Hausenblas <michael.hausenblas@deri.org>
Date: Fri, 31 Jul 2009 09:59:38 +0100
To: Ian Hickson <ian@hixie.ch>, Manu Sporny <msporny@digitalbazaar.com>
CC: HTML WG <public-html@w3.org>, RDFa TF list <public-rdf-in-xhtml-tf@w3.org>
Message-ID: <C698710A.704F%michael.hausenblas@deri.org>
Ian,

>>> For example, the use of prefixes
>> 
>> If I understand you correctly, the use of prefixes is a "personal
>> preferences based on design philosophy" disagreement that you have as
>> you have yet to produce a technical problem with the use of prefixes.
>> How does that feature break UAs?
> 
> I don't understand what you mean by "break UAs".
> 
> Prefixes are widely documented to be an antipattern in language design.
> For example, see this e-mail:
> 
>    http://lists.w3.org/Archives/Member/w3c-archive/2009Jul/0125.html
> 
> ...where I give a quite detailed analysis of why prefixes are a feature of
> poor language design.

With my RDFa TF and DERI AC Rep hat off I must say I don't understand this.
I indeed took a look at the provided references (interesting) but fail to
see the deeper problem.

Let me step back.

I'm not talking about prefixes/XMLNS now, but about namespaces in the sense
of [1]. In my understanding *every* 'decentralised' language (be it a
programming language such as Java or a markup language such as XML-based
things) needs a mechanism to unambiguously assign global names to locally
defined items. This is the context necessary to deal with the decentralised
aspect: everyone's free to come up with a 'System' class, e.g., in Java -
and you put it in your package, say. org.deri.commons.System, and hence both
machines and humans know, which System class you mean. Same holds true for
XML, RDF, etc. -  this is IMO not poor language design, this is very clever.

Can you please enlighten me what I've been missing? Maybe you're addressing
a different issue as I'm thinking of, but I'd really like to understand this
...

Cheers,
      Michael

[1] http://en.wikipedia.org/wiki/Namespace

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Ian Hickson <ian@hixie.ch>
> Date: Fri, 31 Jul 2009 08:23:24 +0000 (UTC)
> To: Manu Sporny <msporny@digitalbazaar.com>
> Cc: HTML WG <public-html@w3.org>, RDFa TF list <public-rdf-in-xhtml-tf@w3.org>
> Subject: Re: Publishing a new draft (HTML5+RDFa)
> Resent-From: RDFa TF list <public-rdf-in-xhtml-tf@w3.org>
> Resent-Date: Fri, 31 Jul 2009 08:24:10 +0000
> 
> On Fri, 31 Jul 2009, Manu Sporny wrote:
>>> 
>>> The reason microdata is in HTML5 and RDFa is not is that RDFa has
>>> fundamental technical problems
>> 
>> As has been stated numerous times, what you are claiming to be
>> "technical problems" are, in fact, "personal preferences based on design
>> philosophy".
> 
> By "technical problems" I mean problems with the design, as opposed to
> editorial problems. They're primarily usability issues, which are to some
> extent subjective. I make no apology for having an opinion on what makes a
> usable language; it's my job to have such an opinion.
> 
> Generally speaking, my position on this topic is a straightforward one:
> simpler is better.
> 
> RDFa fails at being "simple" in a number of ways which I detailed in my
> last e-mail. I consider these problems to be serious.
> 
> 
>> There was a very long set of discussions that we've had that resulted in
>> every demonstrable technical issue that HTML5+RDFa has, being recorded
>> here:
>> 
>> http://rdfa.info/wiki/rdfa-in-html-issues
>> 
>> We asked that others, including you, modify the wiki page to document
>> real technical problems.
> 
> It's not my job to maintain your issues list.
> 
> 
>>> For example, the use of prefixes
>> 
>> If I understand you correctly, the use of prefixes is a "personal
>> preferences based on design philosophy" disagreement that you have as
>> you have yet to produce a technical problem with the use of prefixes.
>> How does that feature break UAs?
> 
> I don't understand what you mean by "break UAs".
> 
> Prefixes are widely documented to be an antipattern in language design.
> For example, see this e-mail:
> 
>    http://lists.w3.org/Archives/Member/w3c-archive/2009Jul/0125.html
> 
> ...where I give a quite detailed analysis of why prefixes are a feature of
> poor language design.
> 
> 
>>> the exclusive use of URIs for identifiers
>> 
>> Again, if I understand you correctly, the use of "URIs-as-identifiers"
>> is a "personal preferences based on design philosophy" disagreement that
>> you have as you have been unable to produce a technical problem with the
>> use of "URIs-as-identifiers". How does that feature break UAs?
> 
> Exclusively using URIs for identifiers is bad language design because URIs
> are a poor form of identifier for many things. This is why few languages
> use them as such -- for example, programming language usually use simple
> tokens as identifiers. URIs are good for identifying resources with a
> scheme, host, and path, but not for verbs or predicates. Using URIs for
> features which they aren't suitable for doesn't break UAs, it hurts
> _authors_, which is a far worse problem.
> 
> 
>>> the use of rev="", the use of rel="" in a manner incompatible
>>> with the rest of HTML
>> 
>> What is the "technical problem" here? How is this breaking UAs?
> 
> rev="" has been shown to be poorly understood by authors.
> 
> The problems with rel="" have been discussed to death by Julian and
> others, and I won't go into them here.
> 
> 
>>> the overly complicated processing model
>> 
>> Again, does this break UAs?
> 
> It makes the language bad. That's a much bigger problem.
> 
> 
>> We have more than 7 RDFa processor implementations now, so the issue
>> isn't developer-oriented.
> 
> Did you see the number of problems Google had with its RDFa documentation?
> That's a sign.
> 
> 
>> If you mean that it's overly-complicated for authors, then it might be
>> -- but the same amorphous claim could be made for large swaths of HTML5,
>> SVG and Javascript.
> 
> It _has_ been made of SVG, yes. If you have specific part of HTML5 that
> are too complex for authors, let me know, I'll fix them. I can't speak for
> JavaScript, I'm not directly involved in that work.
> 
> 
>> So, what exactly is the "technical problem" with the processing model?
> 
> It's incredibly complicated.
> 
> 
>>> the presence of features that aren't necessary (such as per-value data
>>> typing)
>> 
>> Again, your personal preference. There are some that would like to be
>> able to assign types to data. How is this a "technical problem"?
> 
> What is the use case for per-value data types?
> 
> 
>>> the ability to include multiple name-value pairs per element.
>> 
>> Personal preference - what "technical problem" does this create in UAs?
> 
> It makes the language incomprehensible for authors.
> 
> 
> Complexity for authors is one of my most important concerns in HTML5's
> development. You can dismiss this concern as being a "personal preference"
> if you like. Meanwhile, microdata is solving the same problems with orders
> of magnitude less complexity.
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> 
Received on Friday, 31 July 2009 09:00:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 31 July 2009 09:00:31 GMT