Re: [xml-dev] A Namespace Proposal

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.

In a message dated 12/13/2010 2:47:33 P.M. Eastern Standard Time, petexmldev@codalogic.com writes:

I've been thinking about the various namespace ideas that have appeared on
the list, in particular Michael Kay's proposal for namespaces, but also
trying to make sure it works for Amy's automated XML1.0 to XML??? converter
principle, without requiring heuristics to map things like
http://www.w3.org/1999/XSL/Transform to org.w3c.www.1999.XSL.Transform. I
think this is important because a parser ideally wants to present
http://www.w3.org/1999/XSL/Transform to higher layers rather than
org.w3c.www.1999.XSL.Transform in this case.

So here goes:

Namespaces SHOULD use the reversed domain name form, e.g.
org.example.schema. For compatibility with XML 1.0, namespaces MAY use the
URI form via setting up namespace aliases which is discussed later in the
proposal.

An element or attribute name has the form:

name = ( (namespace | namespace_alias ) ":" )? local_name

e.g.: org.example.schema:my_name

The namespace used in an element's name becomes the active namespace and is
applied to all of its children that don't themselves have an explicitly
specified namespace. Thus, in:

<org.example.schema:foo>
<bar/>
</org.example.schema:foo>

'bar' is in the org.example.schema namespace and the example is equivalent
to:

<org.example.schema:foo>
<org.example.schema:bar/>
</org.example.schema:foo>

To set no namespace, leave the namespace part of the name empty, but include
the ':' that separates the namespace from the local name, for example:
<:foo/>

For compatibility with XML 1.0, an attribute name without a namespace or
namespace_alias is always in the empty namespace, as opposed to the active
namespace. Thus for an attribute the name 'foo' is always equivalent to
':foo'.

To allow compatibility with XML 1.0, and to a lesser degree brevity,
namespace aliases maybe setup. This is done using 'magic' PIs that have the
name 'xml:nsalias' which contain multiple attributes in which the name of
the attribute specifies an alias name and the value of the attribute
specifies the namespace name. These PIs are primarily intended for the
parser and in general are not presented to the application.

Thus:

<?xml:nsalias xsl="http://www.w3.org/1999/XSL/Transform" ?>

establishes "xsl" as an alias of "http://www.w3.org/1999/XSL/Transform".

XML alias mappings exist from the point at which they are defined until the
end of the XML document. (In other words, there is a single namespace alias
mapping repository that is not aware of the element nesting.) Aliases
SHOULD NOT be reassigned from one namespace to another.

A namespace alias must match XML's NCName production. To reduce the
potential for conflicts with explicit namespaces, namespace aliases SHOULD
NOT contain the '.' character.

Wherever an aliases character sequence matches the prefix of an element or
attribute name, the namespace of the element or attribute becomes that of
the namespace associated with the alias.

For example, if the above alias is set up:

xsl:stylesheet

is conceptually equivalent to:

http://www.w3.org/1999/XSL/Transform:stylesheet

although of course the latter is not a valid XML name.

As in the case of specifying the namespace directly (e.g.
org.example.schema:foo), the namespace associated with the namespace alias
becomes the active namespace.

A namespace alias may also be used in the interests of brevity, for example
the following is equivalent to the earlier example:

<?xml:nsalias s="org.example.schema"?>
<s:foo>
<bar/>
</s:foo>

Any thoughts?

Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using C++ XML
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php