On Sun, 2 Oct 2005, James M Snell wrote:
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.
Ah; I misunderstood. I believed that you were saying that you were
augmenting the proposed namespaces by saying 'you can put them in ace for
ease, or in the feed history (for example) namespace if you want'.
If you're not saying that and instead saying 'you will use the ace
namespace for all these proposed extensions' then things make a whole lot
more sense.
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.
The above misunderstanding explains what I'm missing, and explains the
rest of the misunderstandings.
I had understood that you were duplicating the functionality of those
proposals to reduce the necessary space required in the files, rather than
saying that all the proposed extensions should move under a single
namespace instead.
Apologies.
--
Gerph <http://gerph.org/>
