Cytoscape Wiki|
← Revision 1 as of 2007-06-27 21:24:35
Size: 3388
Comment:
|
← Revision 2 as of 2007-06-27 23:51:26 →
Size: 4920
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| Line 6: | Line 5: |
| Line 10: | Line 8: |
| Line 16: | Line 13: |
| Line 18: | Line 14: |
| 6/27/2007: Not yet completely written |
6/27/2007: Not yet completely written |
| Line 21: | Line 17: |
| Line 27: | Line 22: |
| Line 29: | Line 23: |
|
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. |
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. |
| Line 38: | Line 26: |
|
== 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. |
|
| Line 39: | Line 29: |
|
== 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. |
|
| Line 46: | Line 31: |
| Line 47: | Line 33: |
|
* Cytoscape.getNodeAttributes(String namespace) * Cytoscape.getEdgeAttributes(String namespace) |
* Cytoscape.getNodeAttributes(String namespace) * Cytoscape.getEdgeAttributes(String namespace) |
| Line 50: | Line 36: |
|
2. All get and set routines will get additional signatures to by adding a '''String namespace''' argument that will indicate the namespace to be used. 3. 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. |
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 == 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... |
| Line 53: | Line 43: |
| == Comments == |
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 "://") |
RFC Name : Supporting "namespaces" for attributes |
Editor(s): ScooterMorris |
About this document
This is an official Request for Comment (RFC) for supporting the concept of namespaces for CyAttributes.
For details on RFCs in general, check out the [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments Wikipedia Entry: Request for Comments (RFCs)]
Status
- 6/27/2007: Not yet completely written
How to Comment
To view/add comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Here is an example to get things started: ["/Comment"].
Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.
Proposal
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:
- Cytoscape.getNodeAttributes and Cytoscape.getEdgeAttributes will get additional signatures:
- Cytoscape.getNodeAttributes(String namespace)
- Cytoscape.getEdgeAttributes(String namespace)
All get and set routines will get additional signatures to by adding a String namespace argument that will indicate the namespace to be used.
- 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
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
- - 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".