Re: ACE - Atom Common Extensions Namespace

[Thomas Broyer]

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.


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.

-1 to ACE, for the very same reasons.

--
Thomas Broyer

Re: ACE - Atom Common Extensions Namespace

[Thomas Broyer]

Martin Duerst wrote:


At 07:04 05/10/03, Walter Underwood wrote:
>
>--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren
><[EMAIL PROTECTED]> wrote:
>>
>> 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.)
>
>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
>with the same name.

Yes. The W3C server could certainly be tweaked to allow that,
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

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

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

Re: ACE - Atom Common Extensions Namespace

[A. Pagaltzis]

* Antone Roundy <[EMAIL PROTECTED]> [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,
-- 
Aristotle Pagaltzis // 

Re: ACE - Atom Common Extensions Namespace

[Antone Roundy]

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.

Re: ACE - Atom Common Extensions Namespace

[Henry Story]

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

Re: ACE - Atom Common Extensions Namespace

[Martin Duerst]

At 07:04 05/10/03, Walter Underwood wrote:
>
>--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren
><[EMAIL PROTECTED]> wrote:
>>
>> 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.)
>
>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
>with the same name.

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


Regards,   Martin. 

Re: ACE - Atom Common Extensions Namespace

[Martin Duerst]

At 16:45 05/10/02, James M Snell wrote:
>
>http://www.w3.org/2005/Atom-extensions works for me... assuming, of 
course, that Those-Who-Officially-Assign-Such-Things go along with it.


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. 

Re: ACE - Atom Common Extensions Namespace

[Mark Nottingham]

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:


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-DraftSeptember  
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 "Sect

Re: ACE - Atom Common Extensions Namespace

[Justin Fletcher]

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 

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

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.


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 ?


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 ?


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.


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 ?


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.




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


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


There is no duplicated functionality.


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


There is no conflict resolution.


  - The organisation of a central registration scheme - something
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
'common'


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 
specifications

are updated


Again, this is nonsensical.  the specifications define the elements that 
are within the ace namespace.  The el

Re: ACE - Atom Common Extensions Namespace

[Justin Fletcher]

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



Bill de hÓra wrote:


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.



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:

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

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

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.


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 
... Some may sing the wrong words to the wrong melodies;
It's little things like this that matter to me.

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

Bill de hÓra wrote:


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.
   



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:

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

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

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

Re: ACE - Atom Common Extensions Namespace

[Bill de hÓra]

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.

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

cheers
Bill

Re: ACE - Atom Common Extensions Namespace

[Walter Underwood]

--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren <[EMAIL PROTECTED]> 
wrote:
> 
> 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.)

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

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

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


Anne van Kesteren wrote:



Quoting "A. Pagaltzis" <[EMAIL PROTECTED]>:


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.



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

Re: ACE - Atom Common Extensions Namespace

[Anne van Kesteren]

Quoting "A. Pagaltzis" <[EMAIL PROTECTED]>:

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.


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


--
Anne van Kesteren

Re: ACE - Atom Common Extensions Namespace

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [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,
-- 
Aristotle Pagaltzis // 

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

Eric Scheid wrote:


On 2/10/05 3:54 PM, "James M Snell" <[EMAIL PROTECTED]> 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.
   



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.

 

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
require mU, right?

 


that would be my interpretation.

- James

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

A. Pagaltzis wrote:


Hi James,

* James M Snell <[EMAIL PROTECTED]> [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.

 


Agreed. I'll change it.


3.  The Atom Common Extensions 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.
   



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

 


Agreed.


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



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

 


Hey, I stink at names.  I'll make no appologies for that ;-)


4.  Registry of Atom Common Extensions

  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?
 



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

Re: ACE - Atom Common Extensions Namespace

[James M Snell]

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


Anne van Kesteren wrote:


Quoting James M Snell <[EMAIL PROTECTED]>:


 The Atom Common Extensions Namespace
   "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.

Re: ACE - Atom Common Extensions Namespace

[Anne van Kesteren]

Quoting James M Snell <[EMAIL PROTECTED]>:

 The Atom Common Extensions Namespace
   "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

Re: ACE - Atom Common Extensions Namespace

[A. Pagaltzis]

Hi James,

* James M Snell <[EMAIL PROTECTED]> [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.

> 3.  The Atom Common Extensions 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.

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

>The Atom Common Extensions Namespace
>  "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.

> 4.  Registry of Atom Common Extensions
> 
>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 // 

Re: ACE - Atom Common Extensions Namespace

[Eric Scheid]

On 2/10/05 3:54 PM, "James M Snell" <[EMAIL PROTECTED]> 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.

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.

ACE - Atom Common Extensions Namespace

[James M Snell]

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-DraftSeptember 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 Consi