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â.
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
(Changes and deletions within referenced specifications are another
issue, but can controlled by versioning.)
Approach - Referencing:
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.)
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.
statement is an alternative to a wholesale switch in vocabulary allowed by
reassigning the meaning of the null prefix.
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.
requires a locking or transaction protocol.)
specification can be included, by copy or transformation.
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
Extensions can be
mutual if both scopes reference each other.
This is particularly useful to collect properties such as
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.
specifications may be included in a referencing specification by inheritance
treatment of inheritance and polymorphism is a separate but related
Perhaps the above can be further simplified as
path expression can begin with a resource name.
And for convenience in the use of names in
* A path
expression can be aliased.
* A using
statement can be introduced.
variables can be introduced.
expressions can follow a reference.
* Nodes in a
path expression can have entry and exit (backtracking) events.