Justin Fletcher wrote:
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 ?
Same thing that implementors should do when they encounter any elements
from different namespaces with equivalent meanings. For example, what
should implementors do if they encounter dc:date within an Atom entry?
It's up to the implementation to decide how to handle.
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 ?
The ace namespace does not take precedence over other extension
namespaces. It's just there to allow folks from having to invent new
namespaces for extensions that actually go through the effort of being
standardized In The IETF Way.
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 ?
Original namespace? That makes no sense. The ace namespace would be THE
ONLY namespace for elements and attributes defined within it.
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 ?
eh? base namespace? original namespace? I think you're missing
something here.
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 ?
There is no "ace:fh-foo from the http://... whatever namespace". It's
just element "foo" in the ace namespace. In other words, this document
specifies a special XML namespace that is conceptually not unlike the
http://www.w3.org/XML/1998/namespace namespace used by the xml:lang,
xml:base and xml:id attributes. Individual specs can define
elements/attributes as belonging to the ace namespace. Updates to those
specs can update those elements/attributes as appropriate.
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 ?
This is nonsensical. It would be up to the feed history specification
to define it's elements as being within the ace namespace -- a which
time the existing feed history namespace would cease to exist.
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.
Again, nonsensical. There is no additional baggage brought in by the
ace namespace. The only thing that ace does is provide a common
namespace underwhich various extensions can be defined. It is there for
use by specification authors to keep from having to introduce new
namespaces for new standardized extensions.
My thoughts on this are that bundling together elements from different
namespaces means ...
- More work for implementors to support, due to duplicated
functionality
There is no duplicated functionality.
- More work for implementors to support, due to conflict resolution
There is no conflict resolution.
- The organisation of a central registration scheme - something
that namespaces try to avoid
This is a plus in this case as it means that only things that are really
"common extensions" become part of the "common extensions" registry.
- Continued management to maintain a list of those elements which are
'common'
Again, this is not a challenge. The success of this namespace will
depend directly on how much work is necessary for an extension to become
part of the core.
- Continued management to update the elements as the base
specifications
are updated
Again, this is nonsensical. the specifications define the elements that
are within the ace namespace. The elements are not added to the ace
independently of the specs in which the elements are defined.
- One more specification to comply to
For the specification authors for whom this is written for. This spec
does not introduce any new requirements for Atom implementors.
+ 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.
Question: under this logic, why was xml:id [1] not defined in it's own
namespace?
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.
Once again, this spec does not introduce any new requirements for
implementors.
- James
[1] http://www.w3.org/TR/2005/REC-xml-id-20050909/
