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â.
Objectives:
·
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.)
·
Referencing
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.)
·
Using
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:
·
References
A reference type is a basic type whose value can be (or
can be resolved to) a name or a name expression.
·
Paths
A path is a name expression that can traverse reference
values as well as hierarchies.
Approach- Use
·
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.
Cart
