W3C home > Mailing lists > Public > public-appformats@w3.org > August 2007

Re: widget namespace

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Tue, 28 Aug 2007 09:21:04 -0700
To: "Marcos Caceres" <marcosscaceres@gmail.com>
Cc: "Anne van Kesteren" <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>, public-appformats-request@w3.org, "Robin Berjon" <robin@berjon.com>
Message-ID: <OFD751E1B1.87849DCE-ON88257345.0057C75A-88257345.0059D20A@us.ibm.com>

Hi Marcos,
In answer to your question about whether anyone feels strongly about the
namespace issue, I feel strongly that any new grammar defined by W3C should
sit on top of a foundation of XML namespaces and would recommend to my A/C
rep to vote "no" against any specifications that defined a new language
that did not do so.

To me, it is glaringly obvious that a standards organization should
leverage whatever tools are available to ensure that the technologies it
defines are robust and extensible. In the realm of angle-bracket markup
languages, the relevant tools are XML namespaces along with a proper schema
definition using XML Schema or RelaxNG. These XML tools prevent ambiguities
in the language definition and provide a clear definition of extensibility
points for both the language design committee (W3C in this case) and 3rd
parties who need to add their own elements and attributes due to the
special requirements of their workflows. (Note that HTML/HTML5 is a special
case where the world has gone through a hugely expensive and inefficient
process of recreating quirks found in leading implementations in order to
achieve a reasonably useful defacto standard.)

My primary reason for recommending the use of namespaces and schema is
mainly from a language design perspective. It's the proper way to design
languages. However, that doesn't mean that clients have to enforce all or
any of the formal language mechanisms. For example, it is unusual that
clients perform validation. The big question is whether to require
well-formedness checks in the client. I would recommend yes because I don't
think we want to launch another decades-long effort to cross-replicate the
quirks from other widget clients. Widget designers are capable of learning
that they need to use quotes on attributes and have close tags for every
start tag versus all of the other things they need to learn to create a

Thanks for asking.

Jon Ferraiolo <jferrai@us.ibm.com>
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865

             "Marcos Caceres"                                              
             mail.com>                                                  To 
             Sent by:                  "Robin Berjon" <robin@berjon.com>   
             public-appformats                                          cc 
             -request@w3.org           "Anne van Kesteren"                 
                                       <annevk@opera.com>, "WAF WG         
             08/28/2007 05:01          <public-appformats@w3.org>          
             AM                                                    Subject 
                                       Re: widget namespace                

> A well designed format is one for which people can make uses and
> extensions unforeseen by the creator. Putting a namespace here is
> zero-cost, not putting it is just begging to look stupid down the line.

Appealing to our ego's is a nice rhetorical trick, but it's better to
keep the arguments on a technical level:-)

> FWIW, Joost's internal widget manifest format uses a namespace, which
> makes it easier to implement multiple widget formats too.
> > Using namespaces here just complicates things for authors who want
> > to copy and paste lines of codes without the level of indirection
> > given by namespaces (where they would have to copy the namespace
> > decleration too).
> Experience shows authors are not that silly, it's just a handful of
> specification writers who think that's complicated :)

I'm not too phased by the namespace issue... and I don't think Anne is
either. I do however support Anne's position and reasoning. However, I
am inclined to put it back in.

Anyone one else feel strongly about having a namespace? The namespace
would be:


If other people want it and think its a good idea then I am happy to
put it back in the spec.

Kind regards,
Marcos Caceres

(image/gif attachment: graycol.gif)

(image/gif attachment: pic12742.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 28 August 2007 16:23:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:19 UTC