Subject: ACE - Atom Common Extensions Namespace

From: James M Snell <[email-masked]>
Date: Sat, 01 Oct 2005 22:54:54 -0700

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

Network Working Group                                           J. Snell
Internet-Draft                                            September 2005
Expires: March 5, 2006

                    Atom Common Extensions Namespace
                     draft-snell-atompub-ace-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 5, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document introduces a common namespace for standardized
   extensions to the Atom 1.0 Syndication Format.

Snell                     Expires March 5, 2006                 [Page 1]

Internet-Draft                   A.C.E.                   September 2005

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.   Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
   3.   The Atom Common Extensions Namespace . . . . . . . . . . . . . 3
   4.   Registry of Atom Common Extensions . . . . . . . . . . . . . . 3
   5.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
   7.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
        Intellectual Property and Copyright Statements . . . . . . . . 5

Snell                     Expires March 5, 2006                 [Page 2]

Internet-Draft                   A.C.E.                   September 2005

1.  Introduction

   The Atom Common Extensions Namespace is a single XML Namespace with
   which standardized Atom 1.0 extensions MAY be associated.  This
   document defines the common namespace and creates an IANA Registry of
   Atom Common Extensions.

2.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.

3.  The Atom Common Extensions Namespace

   The Atom Common Extensions Namespace is an expansion of the Atom 1.0
   Syndication Format XML Namespace.  XML elements and attributes
   defined as Atom 1.0 Extensions that are standardized in accordance to
   the process specified in "Section 4: Registry of Atom Common
   Extensions" MAY use the Atom Common Extensions Namespace as an
   alternative to defining their own extension specific XML namespaces.

   The Atom Common Extensions Namespace
     "http://www.w3.org/2005/Atom/ace"

4.  Registry of Atom Common Extensions

   This specification defines a Registry of Atom Common Extensions
   maintained by IANA.  The members of the Registry consist of Atom 1.0
   Extensions that define XML elements and attributes falling under the
   the Atom Common Extensions Namespace.  New assignments are subject to
   IESG approval as outlined in [RFC2334].  Requests should be made by
   email to IANA, which will then forward the request to the IESG
   requesting approval.  The request should use the following template:

   o  Name: (A unique informal name by which the extension can be
      referred.)
   o  Description:
   o  Elements and Attributes: (definitions for each of the XML elements
      and attributes to be associated with the Atom Common Extensions
      Namespace)
   o  Security Considerations:

   Extension elements and attributes introduced by new assignments to
   the registry MUST be uniquely named within the Atom Common Extensions
   Namespace and MUST NOT duplicate the function and purpose of other
   elements and attributes specified by other extensions in the

Snell                     Expires March 5, 2006                 [Page 3]

Internet-Draft                   A.C.E.                   September 2005

   registry.

5.  Security Considerations

   There are no security considerations introduced by this
   specification.

6.  IANA Considerations

   This specification creates a Registry of Atom Common Extensions as
   described in section 4.

7.  References

   [I-D.ietf-atompub-format]
              Sayre, R. and M. Nottingham, "The Atom Syndication
              Format", draft-ietf-atompub-format-11 (work in progress),
              August 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2334]  Luciani, J., Armitage, G., Halpern, J., and N. Doraswamy,
              "Server Cache Synchronization Protocol (SCSP)", RFC 2334,
              April 1998.

   [W3C.REC-xml-infoset-20040204]
              Tobin, R. and J. Cowan, "XML Information Set (Second
              Edition)", W3C REC REC-xml-infoset-20040204,
              February 2004.

   [W3C.REC-xml-names-19990114]
              Hollander, D., Bray, T., and A. Layman, "Namespaces in
              XML", W3C REC REC-xml-names-19990114, January 1999.

Author's Address

   James M Snell

   Phone:
   Email: [email-masked]
   URI:   http://snellspace.com

Appendix A.  Acknowledgements

   TBD

Snell                     Expires March 5, 2006                 [Page 4]

Internet-Draft                   A.C.E.                   September 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Snell                     Expires March 5, 2006                 [Page 5]

---

From: Eric Scheid <[email-masked]>
Date: Sun, 02 Oct 2005 17:20:12 +1000

> review the attached and let me know what you think.

Do you want to start it off as an empty container, or might it be strategic
to submit it with a number of extensions mentioned by reference. If the
latter, it would serve a bootstrapping purpose for developers new to Atom.

A bit like that page for RSS which enumerates a collection of extensions.

----

What about mustIgnore/mustUnderstand? An extension sharing the ACE ns can't
require mU, right?

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 2 Oct 2005 09:29:53 +0200

Hi James,

* James M Snell <[email-masked]> [2005-10-02 08:05]:
> 1.  Introduction
> 
>    The Atom Common Extensions Namespace is a single XML
>    Namespace with which standardized Atom 1.0 extensions MAY be
>    associated.

This “MAY” seems really out of place here. Not everything is a
nail with respect to the RFC2119 hammer. Informal language seems
called for, instead.

>    XML elements and attributes defined as Atom 1.0 Extensions
>    that are standardized in accordance to the process specified
>    in "Section 4: Registry of Atom Common Extensions" MAY use
>    the Atom Common Extensions Namespace as an alternative to
>    defining their own extension specific XML namespaces.

Again, it seems inappropriate to invoke RFC2119 in this instance.

>      "http://www.w3.org/2005/Atom/ace"

Can anyone stick things in the W3C URI space willy-nilly?

In any case, my preference would be something like “/ext”, due to
both a strong dislike of cutesy names and the fact that the “a”
in “ace” redundantly expands to Atom which is already there.

>    Extension elements and attributes introduced by new
>    assignments to the registry MUST be uniquely named within
>    the Atom Common Extensions Namespace and MUST NOT duplicate
>    the function and purpose of other elements and attributes
>    specified by other extensions in the registry.

Might it be prudent to require of extensions that they define a
prefix for all their elements?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 02 Oct 2005 09:35:28 +0200

>    "http://www.w3.org/2005/Atom/ace"

It should probably be something like
     "http://www.w3.org/2005/Atom-extensions

Having a file and folder of the same name is not technically possible. 
(Although
you could emulate the effect of course with some mod_rewrite.)

The idea seems nice though. Less namespaces for people to learn seems like a
good thing.

-- 
Anne van Kesteren
<http://annevankesteren.nl/>

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 00:45:50 -0700

http://www.w3.org/2005/Atom-extensions works for me... assuming, of 
course, that Those-Who-Officially-Assign-Such-Things go along with it.  
The original .../ace URI was just a working thing pitched with full 
knowledge that it would likely change to something better. (I positively 
stink at coming up with good names for things ;-) ...)

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 00:49:40 -0700

>nail with respect to the RFC2119 hammer. Informal language seems
Agreed. I'll change it.

>Again, it seems inappropriate to invoke RFC2119 in this instance.
Agreed.

>Can anyone stick things in the W3C URI space willy-nilly?
I haven't a clue how these things typically get assigned.  To me, it 
just makes sense for this to extend the existing Atom namespace.

>in “ace” redundantly expands to Atom which is already there.
Hey, I stink at names.  I'll make no appologies for that ;-)

>prefix for all their elements?

If you're talking about namespace prefixes, I don't believe so as I 
don't think it would be something you could reasonably enforce.

- James

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 00:54:11 -0700

>A bit like that page for RSS which enumerates a collection of extensions.
Been thinking about this.  I think it is better to submit extensions by 
reference.  I have a handful of extensions that I'd already like to move 
this direction.

>What about mustIgnore/mustUnderstand? An extension sharing the ACE ns can't
that would be my interpretation.

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 2 Oct 2005 10:41:03 +0200

* James M Snell <[email-masked]> [2005-10-02 09:50]:
> >Might it be prudent to require of extensions that they define
> >a prefix for all their elements?
> 
> If you're talking about namespace prefixes, I don't believe so
> as I don't think it would be something you could reasonably
> enforce.

No, I mean an element name prefix. So f.ex. your indexing
extension would have all its elements start with “idx-” or
“x-” or something whereas the comments one would use “thr-”
maybe.

I’m not sure I like the idea myself, but I’m also a little
apprehensive about just dumping everything into an entirely flat
space.

Regards,

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 02 Oct 2005 11:20:24 +0200

> “x-” or something whereas the comments one would use “thr-”

It is either namespaces or this. As we have namespaces, we should not do this.

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 09:24:06 -0700

+1, introducing something like this would pretty much negate the purpose 
of the common namespace.

---

From: Walter Underwood <[email-masked]>
Date: Sun, 02 Oct 2005 15:04:50 -0700

--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren <[email-masked]> wrote:
> 
> Having a file and folder of the same name is not technically possible. (Although

Namespaces aren't files, only names. So the limitations of some particular
file name implementation are meaningless for namespaces.

Also, some filesystem implementations do allow a file and a folder
with the same name.

wunder
--
Walter Underwood
Principal Software Architect, Verity

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 03 Oct 2005 01:15:38 +0100

> review the attached and let me know what you think.

I don't get it. Why centralize names like this?

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 18:29:48 -0700

>I don't get it. Why centralize names like this?
Illustration-by-example: suppose that I wanted to use all of the 
extensions proposed thus far all at once:

right now I'd end up with:

<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:fh="http://purl.org/syndication/history/1.0"
      xmlns:fr="http://purl.org/syndication/index/1.0"
      xmlns:fa="http://purl.org/atompub/age/1.0"
      xmlns:fh="http://purl.org/syndication/thread/1.0"
      xmlns:nf="http://purl.org/atompub/nofollow/1.0">...</feed>

vs. if they were all covered under a single ace namespace:

<feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:ace="http://www.w3.org/2005/Atom-extensions">

For feed publishers, it is a lot less complex.

Extension publishers would obvious not be required to use the ace 
namespace, but it would likely help in the rollout of new extensions.

- James

---

From: Justin Fletcher <[email-masked]>
Date: Mon, 3 Oct 2005 03:48:29 +0100 (BST)

On Sun, 2 Oct 2005, James M Snell wrote:

> Illustration-by-example: suppose that I wanted to use all of the extensions 
> proposed thus far all at once:
>
> Extension publishers would obvious not be required to use the ace namespace, 
> but it would likely help in the rollout of new extensions.

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 ?

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 ?

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 ?

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 ?

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 ?

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 ?

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.

My thoughts on this are that bundling together elements from different 
namespaces means ...

   - More work for implementors to support, due to duplicated functionality
   - More work for implementors to support, due to conflict resolution
   - The organisation of a central registration scheme - something
     that namespaces try to avoid
   - Continued management to maintain a list of those elements which are
     'common'
   - Continued management to update the elements as the base specifications
     are updated
   - One more specification to comply to
   + 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.

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.

-- 
Gerph <http://gerph.org/>
... Some may sing the wrong words to the wrong melodies;
     It's little things like this that matter to me.

---

From: James M Snell <[email-masked]>
Date: Sun, 02 Oct 2005 20:56:33 -0700

Justin Fletcher wrote:

> 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 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 ?
>
> 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 
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.

> 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.

>   - More work for implementors to support, due to duplicated 

There is no duplicated functionality.

>   - More work for implementors to support, due to conflict resolution

There is no conflict resolution.

>     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

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 

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.

> 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?

> 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/

---

From: Justin Fletcher <[email-masked]>
Date: Mon, 3 Oct 2005 05:58:50 +0100 (BST)

On Sun, 2 Oct 2005, James M Snell wrote:

> 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.
>
> 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.
>
>> 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.

>> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 2 Oct 2005 22:15:59 -0700

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.

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.

A much better thing would be to wait a year or two and see if there's  
a need for such a beast.

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:

> 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
>
>
>
> Network Working Group                                           J.  
> Snell
> Internet-Draft                                            September  
> 2005
> Expires: March 5, 2006
>
>
>    1.    
> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
>    2.   Notational  
> Conventions . . . . . . . . . . . . . . . . . . . . 3
>    5.   Security  
> Considerations  . . . . . . . . . . . . . . . . . . . 4
>    6.   IANA  
> Considerations  . . . . . . . . . . . . . . . . . . . . . 4
>    7.    
> References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
>         Author's  
> Address . . . . . . . . . . . . . . . . . . . . . . . 4
>    A.    
> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

--
Mark Nottingham     http://www.mnot.net/

---

From: Martin Duerst <[email-masked]>
Date: Mon, 03 Oct 2005 18:24:02 +0900

Tim and Paul know who to contact.

 >The original .../ace URI was just a working thing pitched with full 
knowledge that it would likely change to something better.

Good. I wanted to comment that I don't like ACE because the term
is also used in the context of Internationalized Domain Names
(where it stands for ASCII-compatible encoding).

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 03 Oct 2005 18:53:45 +0900

At 07:04 05/10/03, Walter Underwood wrote:
 >Namespaces aren't files, only names.

Yes. But the W3C insists on having an actual file there, just
for documentation at least, or ideally for some machine-readable
information (schema,...).

 >Also, some filesystem implementations do allow a file and a folder

Yes. The W3C server could certainly be tweaked to allow that,
but it would be easier not to have to do that.

Regards,   Martin.

---

From: Henry Story <[email-masked]>
Date: Mon, 3 Oct 2005 13:20:30 +0200

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:
> 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  
> 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.

> 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.

> little bit twisted, considering the W3C and IETF's philosophies  
> about these things ;)
>
> Cheers,
>
>

---

From: Antone Roundy <[email-masked]>
Date: Mon, 3 Oct 2005 09:03:49 -0600

> 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.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 3 Oct 2005 19:34:45 +0200

* Antone Roundy <[email-masked]> [2005-10-03 17:11]:
> The overhead of including multiple  namespace declarations
> isn't going to be that great.

I am coming around to the view that it doesn’t offer anything
worthwhile. My own apprehension at lumping everything into a flat
space, which led me to propose require element name prefixes,
should have tipped me off.

I’m kinda -0 on ACE now, because it doesn’t detract from
anything, but then again that indifference is only symbolic, as
I’m also -1 on putting the currently discussed extensions in this
namespace, for the same reason.

Saving a handful of bytes just doesn’t seem like a reasonable
trade-off worth putting up with all the problems namespaces were
designed to solve. This seems as misguided as my initial thrust
with `rel="in-reply-to"` for the comments extension to avoid a
namespaced extension. I think it’s time (for me no less than
others) to accept that doing things the XML way is sometimes
verbose, and that the benefits of XML simply come at this price.
Let’s do things the right way.

Regards,

---

From: James M Snell <[email-masked]>
Date: Mon, 03 Oct 2005 12:45:58 -0700

> 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

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 03 Oct 2005 22:28:38 +0200

> but it would be easier not to have to do that.
Hey wake up!

If http://www.w3.org/2005/Atom maps to a file system folder, any web 
server that I know of will send a redirect to 
http://www.w3.org/2005/Atom/ and "display" the directory index file 
(index.html, default.htm, etc.)

Moreover, there is precedence at w3.org to use URI without a trailing 
"/" as "public identifiers" (cool URIs?) when they actually are "folders":
See the "last version" links to CSS2 and DOM Level 2 recommendations:
http://www.w3.org/TR/REC-CSS2
http://www.w3.org/TR/DOM-Level-2-Core
http://www.w3.org/TR/DOM-Level-2-HTML
http://www.w3.org/TR/DOM-Level-2-Style
http://www.w3.org/TR/DOM-Level-2-Views
…

I really don't understand why you're discussing this sort of thing… We 
could really have an http://www.w3.org/2005/Atom/extensions namespace.

-- 
Thomas Broyer

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 03 Oct 2005 22:38:26 +0200

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.
>
-1 to ACE, for the very same reasons.

-- 
Thomas Broyer