Being somewhat new to this topic, I am not sure what is new or different here. However, I hope it is clear, and I hope that my suggested approach to abstraction and generalization can lead to considerable simplification.
Three parts of the discussion can be separated - objectives, approach and syntax. For simplification here, I avoid syntax and also avoid use of the phrase “name space”.
· Allow specifications written by different people, at different times, in different places to be used and effectively integrated together.
Thus specifications can reference and use elements in other specifications in various ways.
· Names, within an identified scope, need to be unambiguous, even in the face of additions and extensions to the scopes.
(Changes and deletions within referenced specifications are another issue, but can controlled by versioning.)
Approach - Referencing:
· Name Scope
The name scope for a specification includes all the named specifications it encompasses, inherits or it can reference.
Scopes can be nested.
(Also, URI’s, by definition, are always in scope.)
· Scope Name
The name of a referenced scope can be formed (and possibly aliased) from a resource name that identifies a resource or a specification within that resource.
A resource name can be a URI (with query and fragment), possibly with some qualifier such as a version or date to insure uniqueness.
The fragment can be a path expression.
A resource name can be specified with a type to allow access to data in various forms (XML, microXML, JSON, data base, etc.)
A referencing scope can reference names (and path expressions), within a referenced scope by prefixing them with the scope name.
(Name resolution can be “lazy” allowing specifications to be referenced from libraries as well as data made available during processing.)
Additionally, for convenience:
A . A “using” specification can import (and possibly alias) a subset of the names from the referenced scope.
This “using” statement is an alternative to a wholesale switch in vocabulary allowed by reassigning the meaning of the null prefix.
B. (less desirable) A “using” specification can change the null prefix assumption to that of a new scope.
Also for convenience:
A reference type is a basic type whose value can be (or can be resolved to) a name or a name expression.
A path is a name expression that can traverse reference values as well as hierarchies.
· Use of a referenced specification is by default read only.
(Change requires a locking or transaction protocol.)
· A referenced specification can be included, by copy or transformation.
· A specification in a referencing scope can be locally extended or restricted with specifications from a referenced scope.
· A specification from a referenced scope can be locally extended or restricted in the context of the referencing scope.
· Extensions can be mutual if both scopes reference each other.
This is particularly useful to collect properties such as metadata.
To avoid having to change multiple specifications for new metadata sources, specifications can reference a common directory that can be maintained to include libraries of specifications.
· Referenced specifications may be included in a referencing specification by inheritance
(A full treatment of inheritance and polymorphism is a separate but related topic).
Perhaps the above can be further simplified as follows:
* A path expression can begin with a resource name.
And for convenience in the use of names in general:
* A path expression can be aliased.
* A using statement can be introduced.
* Reference variables can be introduced.
* Path expressions can follow a reference.
* Nodes in a path expression can have entry and exit (backtracking) events.
In a message dated 12/13/2010 2:47:33 P.M. Eastern Standard Time, email@example.com writes:
I've been thinking about the various namespace ideas that have appeared on