Don't get me wrong, I *want* to get these issues resolved, I just don't
think we'll have much hope of coming to a reasonable consensus of many
of these issues until we can get a WG going.
- James
Bill de hOra wrote:
Sorry to hear you're not going to bother; irregardless of my opinion on
this particular extension, it could matter a lot, as supporting
extension namespaces gets to the heart of how Atom was designed.
Particularly I wanted to know if it was physically due to having
multiple namespaces*, inconsistency in extension semantics, or both.
cheers
Bill
* for example, I've seen one issue with the XHTML namespace and how
firefox renders an Atom document.
James M Snell wrote:
I'm not going to bother. For now, I've updated the draft so that
deleted-entry is in it's own namespace again and will leave it that
way. If/when we can get an Atom Extensions WG going we can revisit
the issue of how and when it is appropriate to add new
elements/attributes to the Atom namespace.
- James
Bill de hOra wrote:
James M Snell wrote:
Bill de hOra wrote:
[snip]
[cc'd to the AD]
I see this as a worst practice, and the rationale above as paper thin.
Frankly, I'm unable to conclude this is treating the spec's versioning
policy as anything other than a loophole.
Please explain why the tombstone markup has been placed in the Atom
The reasons are simple:
1. This is a generic capability that is applicable to a broad range of
application cases. That is, it is not application or implementation
specific.
That's quite an assertion; I'll assume you can back it up.
2. Implementors are already starting to face issues with supporting a
broad and growing number of extension namespaces.
What issues are those? Seriously, I'd like to know.
cheers
Bill
