Re: widget namespace

On Wed, 8 Aug 2007, Anne van Kesteren wrote:

>
> On Tue, 17 Jul 2007 00:26:36 +0200, Jason Monberg
> <jason.monberg@dshlt.com> wrote:
>> namespaces are important/critical in this context for extensibility. i am
>> assuming that this file will be used to contain elements common to all
>> widgets as well as elements specific to individual widgets.
>
> Why are they critical for extensibility?

Protocols, and especially W3C endorsed protocols, tend not to stand on their
own. Often, protocols are mixed, especially with XML based ones. Without
namespaces, this most basic of extensibilities is not possible. Maybe not
today, maybe not tomorrow, but once there comes a day that you want to extend
it with, for instance, embedded SVG. When using namespaces, this is easy. When
not using namespaces, things get horribly mixed.

> The format is completely
> separated from everything else in the world and the only likely extensions
> are going to be made by vendors which could use something similar to
>
>    <vendor-extension>
>
> or
>
>    <widget vendor-extension="">

No, the format is not completely separated from the rest of the world. I have
seen many formats around that have root tags as <widget>. Vendors may invent
similar extensions with equal names. Without these being inside a namespace,
we cannot easily distinguish them. Extensions ought to be in their own
namespace, that way you don't need to have specific tags for them, you can let
the extension-designer decide. And, more importantly, two extensions can NEVER
interfere once inside namespaces.

Consider, for example, the way this is done for the XSLT standard. XSLT itself
is inside the XSLT namespace, extensions are declared with a root-level
attribute declaring which namespaces are for (vendor) extensions and other
namespaces are used (SVG, XHTML, proprietary) for intermixing content.

<xsl:stylesheet
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:ext="http://www.myvendor.org/some-extensions"
    xmlns="http://www.w3.org/1999/xhtml"
    extension-element-prefixes="ext">

    <ext:vendor-instruction>
       do something special
    </ext:vendor-instruction>

    <xsl:template match="/">
       <html><body>....

    ...
</xsl:stylesheet>



Namespaces are a vital part of everything that is coded in XML these days.
Many more examples can be used where possible collisions would prevent easy
implementation. By using a namespace, you make sure that this specification
will become rock solid, easy to implement, easy to extend and easy to learn.
To drawback, a couple of characters extra in the main <widget> declaration,
seems minor to me compared to all benefits.

>
> 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).
>

I beg to disagree here. Namespaces are considered a necessary evil nowadays.
Only age-old HTML can do without it, or DTD-based XML. We don't want to go
back to tag soup days. It is not good if we end up in a situation where
implementors must use special algorithms to decide what tag belongs to what
specification.

A namespace does not add complexity, it adds clarity. When it is about
copying: it will be on the same line anyway. When you are worried about
prefixes, it is up to the Widget-creator whether he uses a prefix or not. If
you want a DTD for the format, then I think you should consider a W3C XML
Schema instead (and if you need a DTD anyway, there are ways to have a
non-normative DTD based on a prefix-less Widget format).

<widget xmlns="http://www.w3.org/2007/Widget/Configuration">...


A final thought: maybe it looks now as if the widget will always be confined
inside a zip package, but in the real world things change, especially in a
dynamic internet world. For instance, there's a chance that widgets will be
created or served dynamically with SOAP messages or another messaging format,
that widgets are part of a larger repository etc. All this will be rather hard
to implement when the Widget spec stays namespace-less.

I believe that the widget spec must be in a namespace and that any vendor
extensions must be in a namespace (not being the widget namespace).

Cheers,
-- Abel Braaksma

Received on Wednesday, 8 August 2007 14:26:27 UTC