Meta-pubs again

[Tim Bray]

Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some
of the plausible options that happen when you POST to a meta-pub:

- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or
more collections

The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be
doing that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to
just enhance the Ape.

One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually
adopted both. You could imagine a new attribute atom:***@app:meta

<atom:feed app:meta="collection|workspace|service">

depending on which of the above the server would respond to a POST with.

I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.

-Tim

[James M Snell]

The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI. We don't have
any kind of consistent programmatic way of differentiating the two
different kinds of collections but it's not really clear if we actually
need one yet.

- James

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some of
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or more
collections
The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be doing
that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to just
enhance the Ape.
One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually adopted
<atom:feed app:meta="collection|workspace|service">
depending on which of the above the server would respond to a POST with.
I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.
-Tim

[Bill de hOra]

I have that pattern - we have users who have multiple websites, the list
of sites is a feed and managing sites is a post to the feed. Turns out
that Atom is "sort of" closed under these operations.

Bill

Post by James M Snell
The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI. We don't have
any kind of consistent programmatic way of differentiating the two
different kinds of collections but it's not really clear if we actually
need one yet.
- James

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or
more collections
The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be
doing that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to
just enhance the Ape.
One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually
<atom:feed app:meta="collection|workspace|service">
depending on which of the above the server would respond to a POST with.
I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.
-Tim

[Colm Divilly]

Post by Bill de hOra
I have that pattern - we have users who have multiple websites, the
list of sites is a feed and managing sites is a post to the feed.
Turns out that Atom is "sort of" closed under these operations.
Bill

Post by James M Snell
The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI.

Bill, James,
with the approaches above how do you specify what workspace(s) the
collection should belong to ?

Colm

[Sylvain Hellegouarch]

Post by Colm Divilly

Post by Bill de hOra
I have that pattern - we have users who have multiple websites, the
list of sites is a feed and managing sites is a post to the feed.
Turns out that Atom is "sort of" closed under these operations.
Bill

Post by James M Snell
The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI.

Bill, James,
with the approaches above how do you specify what workspace(s) the
collection should belong to ?
Colm

I guess you can use xml:id for each workspace and use it somehow.

- Sylvain

[Bill de hOra]

Post by Colm Divilly

Post by Bill de hOra
I have that pattern - we have users who have multiple websites, the
list of sites is a feed and managing sites is a post to the feed.
Turns out that Atom is "sort of" closed under these operations.
Bill

Post by James M Snell
The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI.

Bill, James,
with the approaches above how do you specify what workspace(s) the
collection should belong to ?

In the system I work with with; all the users content websites are in a
single workspace. Other collections (inbuilts, tag-based, SNSes etc) are
in their own workspace, so we don't need to split out websites. If I had
to split them out I would tag the posted entry representing the new
website with a category for the workspace (said system tags each
workspace with an atom:category, as switching on atom:title is fragile)

Bill

[Antonio Tapiador del Dujo]

How does this relate with the Service document?

Post by James M Snell
The way we've implemented this in Connections is pretty simple and
effective. We essentially have the concept of a
collection-of-collections -- an atompub collection whose entries each
represent a collection. Within each of the atom:entry elements is an
app:collection element. Create a new collection by posting an entry.
Edit the collection metadata by putting to the edit uri. Each
collection has an entry URI and a collection feed URI. We don't have
any kind of consistent programmatic way of differentiating the two
different kinds of collections but it's not really clear if we actually
need one yet.
- James

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some of
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or more
collections
The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be doing
that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to just
enhance the Ape.
One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually adopted
<atom:feed app:meta="collection|workspace|service">
depending on which of the above the server would respond to a POST with.
I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.
-Tim

[Sylvain Hellegouarch]

Hi Tim,

Interesting that you ask this question now as I was about to do it
yesterday and got distracted. Thanks for starting the discussion ;)

One use I was considering is in an application that wants to associate a
service document dynamically with a resource. For instance a new
user-account could lead to a service document for that user.

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some of
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or more
collections

I'm not quite sure what you describe here. Are those options exclusive
in your mind? How do you create collections?

The way I had considered it was to have a service document which only
goal was to support those meta operations, along those lines:

<?xml version="1.0" encoding="UTF-8"?>
<app:service xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:app="http://www.w3.org/2007/app" xml:lang="en"
xml:base="http://localhost:8080/">
<app:workspace>
<atom:title type="text">Meta service creation</atom:title>
<app:collection href="meta/service/">
<atom:title type="text">Meta service creation</atom:title>
<app:accept>application/atom+xml;type=entry</app:accept>
<app:accept>application/atomsvc+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta workspace creation</atom:title>
<app:collection href="meta/workspace/">
<atom:title type="text">Meta workspace creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta collection creation</atom:title>
<app:collection href="meta/collection/">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
</app:service>


1.a. Creating a new service is allowed either by POSTing a new service
document which can of course would be inspected by the server and
adapted based on implementation constraints. The client would simply
then fetch the definitive service document with a subsequent GET. Here
the POSTed service document is considered as a MLE.

1.b. Creating a new service could also be achieved by posting an atom
entry that would describe how the client would like the server to
initiate the new service (that mechanism is not relaly clear in my mind
yet).

2. To create a new workspace one could send an atom entry, the server
could use the atom:title element as the the title of the workspace. A
default collection might be created too with the entry category elements
as the collection categories. By sending an atom feed several
workspaces could be generated at once.

3. Adding a new collection could be done by an atom entry to create a
single collection or a feed to create several collections at once.


Several questions are unanswered though. For instance when creating a
collection there is a need to refer the workspace which they should be
created in, indeed it might not be the meta-workspace. The first simple
thing that came to mind was to associate xml:id with newly created or
pre-existing workspaces and use those ids somehow.

Another question happens with the PUT requests as well as with the
DELETE. Should the latter mean a complete automatic purge of each
service/workspace/collection that were created?

Post by Tim Bray
The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be doing
that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to just
enhance the Ape.

I've started implementing that as a private example using amplee too but
based on my observations above.

Post by Tim Bray
One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually adopted
<atom:feed app:meta="collection|workspace|service">

What is the atom feed representing here? The collection? What does the
app:meta="service|workspace" mean then?

Post by Tim Bray
depending on which of the above the server would respond to a POST with.
I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.

Hope you're ok I answered ;)

- Sylvain

[Sylvain Hellegouarch]

Post by Sylvain Hellegouarch
Hi Tim,
Interesting that you ask this question now as I was about to do it
yesterday and got distracted. Thanks for starting the discussion ;)
One use I was considering is in an application that wants to associate a
service document dynamically with a resource. For instance a new
user-account could lead to a service document for that user.

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some of
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or more
collections

I'm not quite sure what you describe here. Are those options exclusive
in your mind? How do you create collections?
The way I had considered it was to have a service document which only
<?xml version="1.0" encoding="UTF-8"?>
<app:service xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:app="http://www.w3.org/2007/app" xml:lang="en"
xml:base="http://localhost:8080/">
<app:workspace>
<atom:title type="text">Meta service creation</atom:title>
<app:collection href="meta/service/">
<atom:title type="text">Meta service creation</atom:title>
<app:accept>application/atom+xml;type=entry</app:accept>
<app:accept>application/atomsvc+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta workspace creation</atom:title>
<app:collection href="meta/workspace/">
<atom:title type="text">Meta workspace creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta collection creation</atom:title>
<app:collection href="meta/collection/">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
</app:service>
1.a. Creating a new service is allowed either by POSTing a new service
document which can of course would be inspected by the server and
adapted based on implementation constraints. The client would simply
then fetch the definitive service document with a subsequent GET. Here
the POSTed service document is considered as a MLE.
1.b. Creating a new service could also be achieved by posting an atom
entry that would describe how the client would like the server to
initiate the new service (that mechanism is not relaly clear in my mind
yet).
2. To create a new workspace one could send an atom entry, the server
could use the atom:title element as the the title of the workspace. A
default collection might be created too with the entry category elements
as the collection categories. By sending an atom feed several
workspaces could be generated at once.
3. Adding a new collection could be done by an atom entry to create a
single collection or a feed to create several collections at once.

Following up on what is described above, I'll take a slightly more
enhanced example using your app:meta attribute as well.


<?xml version="1.0" encoding="UTF-8"?>
<app:service xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:app="http://www.w3.org/2007/app" xml:lang="en"
xml:base="http://localhost:8080/">
<app:workspace>
<atom:title type="text">Meta service creation</atom:title>
<app:collection href="meta/service/" app:meta="service">
<atom:title type="text">Meta service creation</atom:title>
<app:accept>application/atom+xml;type=entry</app:accept>
<app:accept>application/atomsvc+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta workspace creation</atom:title>
<app:collection href="meta/workspace/" app:meta="workspace">
<atom:title type="text">Meta workspace creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta collection creation</atom:title>
<app:collection href="meta/collection/" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
<app:collection href="meta/collection/restricted" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
<app:categories fixed="yes">
<atom:category scheme="uri://musicgenre/" term="indie" />
<app:categories>
</app:collection>
<app:collection href="meta/collection/extended" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
<app:categories fixed="no">
<atom:category scheme="uri://musicgenre/" term="indie" />
<app:categories>
</app:collection>
</app:workspace>
</app:service>


First I want to highlight that I'm using three different workspaces
because they represent to me three different operations. It's just
convenience not formal.

I'm using the app:meta attribute which Tim suggested so that automated
clients can set discover the supported operations and set their
expectations. That being said, I'm not yet convinced we can't do without.

The usage of the app:categories element is interesting here.

In the collection with @href="meta/collection/restricted", the server
would ensure that any posted atom entry or feed to generate a new
collection would at least have the atom:category listed or reject the
collection creation. Nothing really new here. However on the collection
with @href="meta/collection/extended" I was considering that the newly
created collection would be ensured to have the atom:category listed. I
think that's interesting to allow the client to provide its own
requirements of category elements while giving a way for the server to add
its own metadata.

I'd like to draw a parallel with how XMPP PubSub handles it with a way for
a peer to configure a node for specific behavior. While I don't think we
need such granularity with AtomPub it's certainly interesting to keep it
in mind.

- Sylvain

[James M Snell]

As an alternative to app:meta... in one of the Connections components,
we include a special atom:category element in the app:collection
identifying the role,

e.g.

<collection href="...">
<atom:title>...</atom:title>
<atom:category scheme="http://.../role" term="blogs" />
</collection>
<collection href="...">
<atom:title>...</atom:title>
<atom:category scheme="http://.../role" term="entries" />
</collection>

- James

[snip]
Following up on what is described above, I'll take a slightly more
enhanced example using your app:meta attribute as well.
<?xml version="1.0" encoding="UTF-8"?>
<app:service xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:app="http://www.w3.org/2007/app" xml:lang="en"
xml:base="http://localhost:8080/">
<app:workspace>
<atom:title type="text">Meta service creation</atom:title>
<app:collection href="meta/service/" app:meta="service">
<atom:title type="text">Meta service creation</atom:title>
<app:accept>application/atom+xml;type=entry</app:accept>
<app:accept>application/atomsvc+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta workspace creation</atom:title>
<app:collection href="meta/workspace/" app:meta="workspace">
<atom:title type="text">Meta workspace creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
</app:workspace>
<app:workspace>
<atom:title type="text">Meta collection creation</atom:title>
<app:collection href="meta/collection/" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
</app:collection>
<app:collection href="meta/collection/restricted" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
<app:categories fixed="yes">
<atom:category scheme="uri://musicgenre/" term="indie" />
<app:categories>
</app:collection>
<app:collection href="meta/collection/extended" app:meta="collection">
<atom:title type="text">Meta collection creation</atom:title>
<app:accept>application/atom+xml</app:accept>
<app:categories fixed="no">
<atom:category scheme="uri://musicgenre/" term="indie" />
<app:categories>
</app:collection>
</app:workspace>
</app:service>
First I want to highlight that I'm using three different workspaces
because they represent to me three different operations. It's just
convenience not formal.
I'm using the app:meta attribute which Tim suggested so that automated
clients can set discover the supported operations and set their
expectations. That being said, I'm not yet convinced we can't do without.
The usage of the app:categories element is interesting here.
would ensure that any posted atom entry or feed to generate a new
collection would at least have the atom:category listed or reject the
collection creation. Nothing really new here. However on the collection
created collection would be ensured to have the atom:category listed. I
think that's interesting to allow the client to provide its own
requirements of category elements while giving a way for the server to add
its own metadata.
I'd like to draw a parallel with how XMPP PubSub handles it with a way for
a peer to configure a node for specific behavior. While I don't think we
need such granularity with AtomPub it's certainly interesting to keep it
in mind.
- Sylvain

[Colm Divilly]

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections.

Just to share how we manage this:

- Clients can create Atompub services by posting a request to a well
known endpoint, the content of the POST is an atom service document. The
request can include a Slug header for the client to suggest how they'd
like the service named. Clients can PUT and DELETE to the URI of the
created service document to update/delete the service.

- We avoid the problem of linking collections to workspaces by only
allowing one workspace per service (yeah that is a cop-out)

- Clients can create Atompub collections in a given service by POSTing
a request to the URI of the service document. The content of this
request is an Atom Feed document, and can contain any collection or feed
level metadata (or any other markup, foreign or not). Again you can
provide a Slug to suggest the name of the collection. You can PUT and
DELETE on the collection URI as you would expect. The service document
is modified to embed a collection declaration for the new collection
(just as a newly POSTed entry is added to the collection feed).

Colm

[Sylvain Hellegouarch]

Post by Colm Divilly

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections.

- Clients can create Atompub services by posting a request to a well
known endpoint, the content of the POST is an atom service document. The
request can include a Slug header for the client to suggest how they'd
like the service named. Clients can PUT and DELETE to the URI of the
created service document to update/delete the service.
- We avoid the problem of linking collections to workspaces by only
allowing one workspace per service (yeah that is a cop-out)
- Clients can create Atompub collections in a given service by POSTing a
request to the URI of the service document. The content of this request
is an Atom Feed document, and can contain any collection or feed level
metadata (or any other markup, foreign or not). Again you can provide a
Slug to suggest the name of the collection. You can PUT and DELETE on
the collection URI as you would expect. The service document is modified
to embed a collection declaration for the new collection (just as a
newly POSTed entry is added to the collection feed).
Colm

What actions do you take on PUT? Do you delete associated members to the
collection on DELETE?

- Sylvain

[Colm Divilly]

Post by Sylvain Hellegouarch

Post by Colm Divilly

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections.

- Clients can create Atompub services by posting a request to a well
known endpoint, the content of the POST is an atom service document.
The request can include a Slug header for the client to suggest how
they'd like the service named. Clients can PUT and DELETE to the URI
of the created service document to update/delete the service.
- We avoid the problem of linking collections to workspaces by only
allowing one workspace per service (yeah that is a cop-out)
- Clients can create Atompub collections in a given service by
POSTing a request to the URI of the service document. The content of
this request is an Atom Feed document, and can contain any collection
or feed level metadata (or any other markup, foreign or not). Again
you can provide a Slug to suggest the name of the collection. You can
PUT and DELETE on the collection URI as you would expect. The service
document is modified to embed a collection declaration for the new
collection (just as a newly POSTed entry is added to the collection
feed).
Colm

What actions do you take on PUT? Do you delete associated members to
the collection on DELETE?

We don't do anything special for PUT, e.g. if you PUT a service doc with
an extra collection declaration in it, that would not cause that
collection to be created. DELETE deletes children of a container resource.

Post by Sylvain Hellegouarch
- Sylvain

[Colm Divilly]

Just to resurrect this thread again,
I’m revisiting how to extract the meta-publishing portions of the first
Atom Hierarchy Draft into a standalone spec independent of hierarchy
considerations. I wanted to share my thoughts on that with this group,
but its rather long winded so I've blogged about it [2]. I'd appreciate
if anyone interested in 'meta-publishing' (creating a AtomPub Collection
via AtomPub) would take a look and provide any feedback they might have.

Short version: IMHO creating a Collection is just like creating a Media
Resource in regular AtomPub, with the side-effect that a new Collection
is also created.

Thanks,
Colm Divilly

[1]
http://www.ietf.org/internet-drafts/draft-divilly-atompub-hierarchy-00.txt
[2] http://cdivilly.wordpress.com/2009/06/12/meta-pubs-again-again/

Post by Tim Bray
Back in January, I posted about the idea of a "meta-publication",
something you can do CRUD on publications or collections. mod_atom
needs something like this. Interestingly, several people wrote back
and said yes, but there was disagreement on the mechanics. Here some
- create a new collection in the same workspace
- create a new workspace in the same service doc with one or more
collections
- create a new service doc with one or more workspaces with one or
more collections
The reason I'm raising this again is that I'm going to enhance the Ape
to test my own implementation (doesn't matter that much which of the
above it does) and since this isn't standardized, I guess I'll be
doing that in a private fork. If there were sufficient experience and
appetite to standardize these semantics, well then, I'd be able to
just enhance the Ape.
One could also think of emulating SQL culture: the ISO SQL committee,
whenever it was faced with a choice between two options, usually
<atom:feed app:meta="collection|workspace|service">
depending on which of the above the server would respond to a POST with.
I'm unconvinced at the moment that we're ready to plunge down the
standardization path, but I thought it would be polite to ask.
-Tim