Antone Roundy wrote:
On Oct 2, 2005, at 11:15 PM, Mark Nottingham wrote:
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.
I have to agree with Mark. Consider this scenario: an extension gets
added to ACE. Someone makes an extension that does the same thing
differently. The market prefers the non-ACE method and adopts it more
widely than the ACE solution. Now not only do you have multiple
namespaces to declare, but one of them has a bunch of elements that
don't get used, yet implementors feel compelled to implement them
because they're part of this special namespace.
Here's another scenario: an extension gets added to ACE, and another
extension gets created that does the same thing better. Because the
first has the ACE stamp of approval, the inferior method gets wide
support, and the superior method dies.
Both scenarios suggest that the market should be given time to choose
best practices rather than some group deciding which practices are
going to get special status in advance. If a feed is going to carry
elements from a bunch of different extensions, it's going to be a
relatively heavy feed anyway. The overhead of including multiple
namespace declarations isn't going to be that great.
All very excellent arguments... this is precisely the kind of feedback I
was looking for. In order for ace to be successful, there would have to
be a significant amount of effort put into making sure that the
extensions that go into it are broadly supported and the best approach
to the problem, neither of which we can do without significant
implementation experience under our belts.
At this point, as the author of the spec, I think it's safe for me to
consider it a non-starter.
thanks for the feedback!
- James
