Re: stepping backward (one more step)

This is not the short message you asked for, because I am not interested in
simply articulating "the other side."  I am attempting to frame the
conflict in a context rich enough to start discerning the path forward.  It
does involve stepping backward farther than earlier proposed, to gain
perspective.

In other words, I apologize in advance for not having had the long time to
re-write this into a truly short letter.  But the architecture clash is not
just a technical issue, it is a policy matter as well.  There are lots of
technical solutions.  We won't select well unless the technical
alternatives have their policy connotations or dependencies better exposed.

<details below>

Al

At 08:34 AM 2000-06-03 -0700, Sam Hunting wrote:
>--- John Cowan <jcowan@reutershealth.com> wrote:
>
>Still waiting for a statement of the Technical Vision/Aesthetic Problem
>with this level of clarity...
>

Clarity is in the ear of the hearer.  Let me know what you think of the
following.

Namespaces as defined in the current W3C Recommendation provide inadequate
structural support for semantic extension of the family of XML dialects.
Therefore they do not provide an architecturally-fit layer interface for
the evolution of the language.  

The issue over relative URI-references in namespace declarations is an
architecturally insignificant glitch which does happen to point attention
at this flaw in the historical bottom-up construction of something
attempting to grow into Tim's architectural vision.

Namespaces, as presently defined, were not viewed by the crafters of the
Recommendation as entities that you would want to recognize with an
Identitfier.  They were right.  The problem is not in the manner of
identification; it is in the framing of the definition of this class.  A
class of non-entities currently stands as an architectural building stone.
That's an architectural problem.

Namespaces have two functions:  1) distinguish [XML markup entity type
names and attribute names] from their peers within a given XML document
instance.  2) connect the XML content marked with these distinguished names
with their proper connotations including binding to appropriate processing.

The architectural vision would recognize the second job as a job for a URI.
 This is based on the premise that a namespace is an entity suitable for
identifying.

The namespaces Rec. does the job of binding markup to appropriate
processing by defining a recognition method: literal text comparison [of
some otherwise known string] with the ns-attr in the namespace declaration.
 No use of this parameter outside this one test is contemplated or
encouraged.  This has been justified by a theory about how namespaces don't
have semantics.  This is technically feasible, but arcane; and according to
the vision, inappropriate.

That is the major policy issue:  namespaces without semantics do not form a
proper parting layer in the evolutionary construction of media [e.g. XML]
for Web use.  Namespaces with defined linking to optional semantics would.
No smaller issue solves the architectural problem, here.


Relative URI-references were a technical glitch and oversight, and are not
the architectural problem.  The architect and the namespaces proponents are
agreed that they don't like local names.  [But in solving the problem we
should figure out that they deserve a place after all.]

The architectural problem is not even just if namespaces are reified and if
reified how identified; the architectural problem is how to define a
stopping point in the incremental definition of XML which is safe for our
long range aspirations in the area of language with defined semantics.

A whole module in the construction of the XML specification system would
include both how names from multiple shared spaces can be mixed in a single
XML instance and how the names so mixed can be associated with
[[definitive] descriptions of] proper connotations.

The namespaces technology or pattern of practice set out in the
Recommendation is diffident about owning up to the possibility that the
names in namespaces bear connotations.  It is correspondingly
under-engineered in the area of binding to connotations and resources
sharing and possibly formalizing these connotations.

We tripped over this issue because of a small technical imperfection in the
crafting of the technically-virtuosic, but vision-impaired, scoping of the
Namespaces Recommendation.  The technicality has to do with the difference
between a URI-reference and a URI, and that there are relative
URI-references which nobody thought about in the process of authenticating
Namespaces as a Recommendation.

In actual fact the function that the Namespaces Recommendation envisioned
was not the function of either a URI or a URI-reference.  The Namespaces
Recommendation didn't want a reference to a resource, it didn't even want a
name for a resource, it just wanted an identifying mark to be applied
within instances of a family of conforming markup uses.  This functional
application is not the function usually connoted by using URIs or
URI-references, and it is not the unit of function that one would specify
if one is preparing the foundations for semantically rich extensions to the
XML family of dialects. 

In terms of decision making, how you feel about "do namespaces come with
connotations" makes a big difference in how you feel a bout "how should
namespaces be identified and their identity indicated."

We can work around the details.  But we will still be hampered in this work
by not sharing a sufficiently concrete set of premises as to the desired
[range of] relationship between syntax and semantics in XML dialects.

Some may think that linking to semantics is out of scope.  There is even
language in the Recommendation that sorta says this.  This is a fundamental
conflict with the architectural vision, where the mission of namespaces is
to carry semantics into documents, not just to support parsing.  [Don't get
flowery in viewing the term 'semantics.'  This includes simple, machinable
things like how a TH in an HTML TABLE qualifies some of the TD elements in
the same TABLE.  You can't do that in syntax.  You need to be able to imply
that in an XML namespace.]


This is an actual problem, not just a theoretical one.  For one thing,
namespaces are being used in the field today for linking to processing by
XSL and other applications.  This is semantics.  The namespace defined by
the XSLT language has a definition and semantics.  It is intended to be
used only in conformance to the restrictions set out in the XSLT
specification.  This is proof by example that there is semantics that
matters that pertains to an existing namespace and within the provisions of
a W3C Recommendation.

More colloquially, people don't import entity names and attribute names
into XML documents just to access the characteristics exposed or discussed
in the Namespaces Rec.  Generally this is done with some expectation,
either on the part of the document instance creator or the the types
vocabulary creator, that some further semantic connotations will be honored.

The properties of a namespace as identified in the Namespaces Rec. do not
extend to this very practical characteristic of actual namespaces.  In that
regard, the document under-specifies the class of entity colloquially
referred to as 'namespaces.'  As a result the current namespaces Rec. does
not define a good layer boundary, if the layering is to support compatible
extension of the semantic power of the language.  We need to figure out how
to wiggle our way from what we have committed to, to a more effective
decomposition of the domain, with minimum damage along the way. 

Binding to semantics is not the job of a separate, higher layer.
Namespaces come with connotations.  So 'namespaces' does not define a layer
in the rationalized layering of processing, it defines a vertical slice
crossing layers.  Laying this all out for maximum simplicity and
extensibility is the job of a re-engineered layer stack where the functions
are layered rationally and not necessarily in layers reflecting the history
of release of XML Recommendations.  A feasible migration path is to be very
careful in articulating a defacto layered model of what the XML Rec. of
record does and does not bind in the processing of XML instances, and what
layers these bindings belong to, so as to have a de_facto baseline from
which to plan the migration to a more rational modularization or layering.

[end of recap of what I see as the major architectural (vision) issue]

[Begin relative-URIs issue.  This is separate, may be a problem vs. the
arcitectural vision or not.]

Relative URIs in namespace usage are a side issue, which is something where
the architectural vision and the Namespaces Recommendation seem to be in
fundamental agreement and both mistaken.

This issue is only related to the big issue because the actual scenarios
where relative URIs have been used are for cases where the semantics is
fully articulated locally, so the functional sufficiency of the markup does
not depend on any un-articulated body of knowledge or a globally-usable
form of reference.  The semantics is all spelled out, and where it is
spelled out is available locally.  No further trip is necessary.

It should be recognized that this pattern of use is functionally whole and
sufficient.  It should also be recognized as within the proper domain of
application of XML, and namespaces in XML.  The Web is neither all in XML
nor is all XML in the Web.  They should be engineered to support one
another, but not to exhaustively contain one another.


Al

Received on Saturday, 3 June 2000 17:09:26 UTC