[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meta-pubs again


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. 

Tim Bray a écrit :
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
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?
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.
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:feed@app:meta 

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



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