On Sun, 2 Oct 2005, James M Snell wrote:
Bill de hÓra wrote:
James M Snell wrote:
As I've been going through the effort of defining a number of Atom
extensions, I've consistently come back to the thought that it would be
interesting to explore the creation of a "Common Extensions Namespace"
under which multiple standardized extensions can be grouped. I've
written an initial draft of the concept but before I submit it as an
Internet Draft, I'd like to get some feedback from the group. Please
review the attached and let me know what you think.
I don't get it. Why centralize names like this?
Illustration-by-example: suppose that I wanted to use all of the extensions
proposed thus far all at once:
right now I'd end up with:
<feed xmlns="http://www.w3.org/2005/Atom";
xmlns:fh="http://purl.org/syndication/history/1.0";
xmlns:fr="http://purl.org/syndication/index/1.0";
xmlns:fa="http://purl.org/atompub/age/1.0";
xmlns:fh="http://purl.org/syndication/thread/1.0";
xmlns:nf="http://purl.org/atompub/nofollow/1.0";>...</feed>
vs. if they were all covered under a single ace namespace:
<feed xmlns="http://www.w3.org/2005/Atom";
xmlns:ace="http://www.w3.org/2005/Atom-extensions";>
For feed publishers, it is a lot less complex.
Extension publishers would obvious not be required to use the ace namespace,
but it would likely help in the rollout of new extensions.
Some questions spring to mind...
What should implementors do when both feed history and ace namespaced
elements with equivilent meanings are present - which of the two should
resolve this conflict ?
What should they do if they wish to add a feed history element and the
equivilent ace namespaced element exists ?
What should they do if they wish to augment a feed history element with an
additional attribute and an equivilent ace namespaced element exists ?
Should all ace namespaced elements be decomposed by the processors so that
they appear to be in the original namespace so as to standardise
processing ?
When comparing documents, does a document that uses the ace namespace for
some elements match as being the same as the equivilent elements given
with the base namespace ?
When outputting documents, should producers try to produce ace namespaced
elements, rather than the base namespaced elements ?
Where the ordering of the base namespaced elements is important, is the
order to be preserved if the elements are converted to the ace namespace,
are ace namespaced elements able to be reordered ?
When the base namespaced elements definitions are updated, is the ace
namespaced definition expected to be updated also ? Will
'ace:fh-foo' from the 'http://purl.org/syndication/history/1.0' namespace
be replaced by 'ace:fh-foo2' from the
'http://purl.org/syndication/history/1.1' namespace when it is updated ?
Can an application which claims feed history compliance, claim ace
compliance even if it does not support all the other ace-contained
standards because it complies to a part of the specification ?
Since elements which are not understood by the processor are ignored, why
would anyone use the ace namespace ? They can get the full functionality
by using the (for example) feed history namespace and will be supported by
all clients that support feed history. If they used the ace namespace they
would only be functional in processors that supported the ace namespace
and the feed history namespace. Just using the feed history alone gives
them all of the benefits and none of the baggage that the ace namespace
would bring along.
My thoughts on this are that bundling together elements from different
namespaces means ...
- More work for implementors to support, due to duplicated functionality
- More work for implementors to support, due to conflict resolution
- The organisation of a central registration scheme - something
that namespaces try to avoid
- Continued management to maintain a list of those elements which are
'common'
- Continued management to update the elements as the base specifications
are updated
- One more specification to comply to
+ Less text in the document for authors to read and write
In my opinion, the use of namespaces separates the functionality of a
particular components from others. It promotes reuse of those elements and
only those elements that are required in a particular system. Bundling
these neatly separated elements into a single namespace seems to go
against this idea.
Maybe I've missed something, but other than reducing the amount of
namespaces that need to be declared, and increasing the amount of work for
implementors, I don't think that this gains much.
--
Gerph <http://gerph.org/>
... Some may sing the wrong words to the wrong melodies;
It's little things like this that matter to me.
