- From: Abel Braaksma (online) <abel.online@xs4all.nl>
- Date: Wed, 8 Aug 2007 13:26:27 +0200 (CEST)
- To: public-appformats@w3.org
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