I really like the ACE proposal, and I think the name is a good one
too :-)
It can't harm to have this option on the table now. No one is forced
to use it.
But I think it will have a few positive effects:
- proposals that use it will have a cool ace namespace name
- proposals that want to use the name will perhaps work a little
harder to
coordinate with other proposals on the table, which can't be a
bad thing.
Synergies between different proposals might be found thereby
reducing the
workload on implementors.
- The namespace will act like a stamp of approval. It will be an
indication
that there is some consensus behind the proposal, and that
things will
play nice together
This is not limiting anyone in any way. Proposals that want to use
the dublin
core, foaf or other namespaces should have no trouble using them.
Proposals
can also decide to use their own name space like the current feed
history
namespace.
Henry Story
On 3 Oct 2005, at 07:15, Mark Nottingham wrote:
My .02, FWIW, and off the top of my head;
I think this is a well-intentioned effort, but at the wrong end of
the process. The market (i.e., users and implementors) should have
a go at sorting out at what's common/prevalent enough to merit this
sort of thing; having a co-ordinated namespace will lead to the
problem of what to lump into it, how to version individual
extensions within it, etc.
And that is a problem that the end user won't to make himself all
alone then.
Since every end user is bound to come up with his own idea of how to
lump things together, thereby creation an explosion of private lumps,
this should in the end
also reduce the workload on implementors.
In other words, some of the benefits of Namespaces in XML -- e.g.,
loose coordination, well-insulated name spaces, ability to change
namespace without changing local name to effect versioning -- will
be lost, all for the sake of saving a few characters. Not worth it,
IMO.
Nothing is lost. All those benefits remain, as I said above. The atom
spec has
been designed to be open, the ace proposal will not and could not
change that.
A much better thing would be to wait a year or two and see if
there's a need for such a beast.
All these little proposals we have now indicates that we should work
preventatively
and at least put the option on the table for proposers to consider.
And, the idea of an XML namespace backed by an IANA registry is a
little bit twisted, considering the W3C and IETF's philosophies
about these things ;)
Cheers,
On 01/10/2005, at 10:54 PM, 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.
- James
