In current (1.x) Wagn, cardnames are segmented with the character '+', and that has a history that isn't imortant here.  What is important is that before we finalize the API and really open the field for Wagn as a development platform, that we want to add some features under the title of 'Namespaces', and those changes are expected to get pretty deep into Wagn's structure.  It is important also as it relates to WagNet, the idea of a network of cooperating Wagns with interlinked content, and it is important to this discussion of how URIs are intepreted in Wagn and Rails.  In both we have the concept of REST, and this is where we will find commonality and connection.  To support this move, we are pretty sure that Wagn's '+' will become '/' to be consistent with URI conventions.

In Rails if I have this nested route:

resource :users do

   resource :roles

end

That would give us routes like this:

/users           Gives index (list) of the users collection

/users/:id     Gives a specific 'user' model resource

/users/:id/roles  Gives the index (list) of a nested collection: roles

/users/:id/roles/:id  The specific nested resource

In Wagn:

/Users      Represents the 'user' model, the default page lists the collection

/Users/:index  A proposed way to access collection elements

Normally

/Gerry       Represents the specific row in /Users and

/Gerry/email Is the email attribute or

/Gerry/roles/1 would be the first of /Gerry's roles (a Pointer attribute)

Or if we had a different Import:

/Users/001/name Would be 'Gerry' instead and

/Users/001/roles/1 would still me his first role

In Wagn terms many of these paths won't actually be cards, but will be aliases or vitual cards.

Let's return and take apart names again.  Externally, we are in the space of URIs, web addresses.  We know we are in a world of many web servers, some with common protocals, and names with certain encodings and structure:  http://host/a/path/on/a/host.html   We can make a map of the pathnames our host will serve and how request are routed based on these paths.  You may have an http server such as Apache that routes a number of prefixes to specific web servers.  For Wagn, that would be a passenger server running Wagn on Ruby on Rails.  All this means is that our rails application gets all the requests with a certain prefix, and any other request may as well be on another host, we don't serve it or have access to it.

Within that space, Rails uses a number of tools to 'route' requests, but the main way is routes layed out in config/routes.rb, and that's where the resource declarations in the example above would go.  A RESTfully routed Wagn just takes over the route space, than means you really don't get to change the controllers, but you can make arbitrary things happen before or after standard events at the model or controller levels.

To nest an external resource we are designing a way to nest namespaces.  You would be able to create a card that says, in effect, /MyModel is a separate namespace from the source Wagn.  We would create a card named 'MyModel' with a special 'Resource' cardtype, a cardtype that attaches a namespace.  It might have settings that are the URI of a REST resource, or a local ActiveRecord model.   Say the model is our user model and there is a record with the name key of 'Gerry', then /MyModel/Gerry would be the collection of my profile's attributes (name, email, rating, roles, ...) so /MyModel/Gerry/email would be just that one value of Gerry's email address.  Note that this is all about names, and it doesn't care how or where the data is stored.  If I have a local ActiveRecord model, they are rows and columns in a table, if they are in the main Wagn namespace, each row/column value is stored as the content of a card complete with history.