## page was renamed from RFCTemplate
## This template may be useful for creating new RFC's (Request for comments)
## This is a wiki comment - leave these in so that people can see them when editing the page

##Fill in RFC Name, primary authors and editors, and the status of the RFC
##Example Status states include: Work in Progress, Open for Comment, Closed

|| '''RFC Name''' : Supporting "namespaces" for attributes || '''Editor(s)''': ScooterMorris || '''Status''': Not yet completely written ||
<<TableOfContents([2])>>

== Proposal ==
##The sections below may be useful when creating an RFC, delete the ones that are not
The proposal is to extend the CyAttributes API to add "namespaces" that would  provide some way to scope a name.  This is particularly important now that plugin authors are being encouraged to use attributes as the primary way to store information related to a node, edge, or network.  Plugin authors are wondering how to make sure their attribute names will be unique.  In addition, namespaces would allow us to restrict attributes to specific networks, nodes, or edges, thus simplifying the presentation of attributes to users.

== Biological Questions / Use Cases ==
== Backward Compatibility ==
By default, there could be a "null" namespace, which would be inferred when the existing CyAttributes API is used.  In this manner, the existing functionality will be preserved, both in terms of the user expectations and in terms of the API.

== Implementation Plan ==
The plan is to extend the existing APIs as follows:

 1. Cytoscape.getNodeAttributes and Cytoscape.getEdgeAttributes will get additional signatures:
  * Cytoscape.getNodeAttributes(String namespace)
  * Cytoscape.getEdgeAttributes(String namespace)
 The existing signatures will return all node and edge attributes as they currently do.
 1. All get and set routines will get additional signatures to by adding a '''String namespace''' argument that will indicate the namespace to be used.
 1. Internal representations of namespaces will need to be determined.  Initially, I would imagine that a namespace will simply be some form of prefix or suffix added to the attribute name.  This would be scanned as appropriate when setting or getting namespaced attributes.  If this turns out to be a bottleneck, we can examine setting up internal maps to the namespaced attributes.
== Comments ==
KarlForner - 6/27/2007

I have one question about the "null" namespace and backward compatibility: if the attributes under a namespace are not visible under the "null" one, that implies that a tool as the nodes attributes browser will not show them, at least without a modification allowing to see/select namespaces. 
And what if we want to display and use attributes belonging to several namespaces ? 
The consequence is that a lot of tools will need to be updated : vizmapper, attributes browser etc... 

So instead if we turn the internal representation of prefixing by a String prefix into a feature : suppose that we could forbid a given character/separator in the attributes names, say ":" or "|", or a substring like "://", this way by using the backward API we can list and read all the attributes, but not create new ones  in namespaces. 
By using the new namespace-aware API, attributes names would be automatically preprended with the namespace prefix followed by the "forbidden" separator. 

So to sum up : 
 - using the existing "backward" API, we will be able : 
     -  to get/create/set any "null" namespace attributes 
     -  to get/set any attributes but not create a new attribute in a namespace 
 - using the new  API, we will be able : 
     -  to get/create/set any attributes in any namespace 
     - attributes names in a namespace will "officially" follow a given format, for instance "namespace://attribute_name". 
 - the API will provide methods to form/parse these namespace attributes names (nobody would have to know that it's "://")
Karl 

----
ScooterMorris - 6/27/2007

I'm assuming that core plugins should (and will) be modified to support the new API.  That's one reason we're looking at a 2.6 implementation.  The idea with the "null" namespace is that it would mimic the current behavior -- that is, it would provide access to all attributes.  We might also need to have a "default" namespace of some sort in the future.

As far as the internal representation, I suspect we'll come up with some sort of syntax like what you've proposed, but I think we should focus on the API and future functionality first, then we can discuss how to implement backwards compatibility.


MikeSmoot - 8/8/07

A couple of thoughts:

 * No "null" namespaces, rather our current namespaces would be "nodes", "edges", and "networks". So there'd only be one getAttributes("namespace name") method.  Current methods getNodeAttributes() would be changed to simply be a call to getAttributes("nodes").
 * What about an inheritance hierarchy for namespaces?  That way you could define a namespace for a network that would automatically include all attributes defined in the "nodes" or "edges" namespace.