Re: stepping backward (one more step)

Al,

I took me a while to digest this, but having got there I strongly agree 
with what you say.  I think you've done a good job of laying out the issues 
at stake.

Specifically, when you say:

>Binding to semantics is not the job of a separate, higher layer.

I think you touch a central issue (regarding *binding* to semantics as 
distinct from *describing* the semantics).

With reference to:
>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.

You have also helped me to crystallize a view that was foggily coming 
together in my head:  relative URIs for namespaces are OK, *provided* that 
the documents containing them are processed in a context that provides an 
appropriate base URI (or environment) for their resolution.  In  the cases 
you raise having "locally articulated semantics", then _any_ base URI is 
appropriate.  I can imagine other cases where documents are intended for 
processing only by a specific application(s) which provides the appropriate 
environment for resolving the namespaces -- such documents would not be 
open to the full exploitative power of the Web, but as you say "nor is all 
XML in the Web".

The question that seems to remain, then, is that the Namespace spec defines 
simple namespace string matching for the purpose of "distinguish [XML 
markup entity type names and attribute names] from their peers within a 
given XML document instance", but does not define a namespace name 
equivalence rule for the second purpose of "connect the XML content marked 
with these distinguished names with their proper connotations".

Is it really needed, or important, that the same equivalence rule is used 
for both of these purposes?  Could we stick with string-equivalence for 
distinguishing among peers, but "absolutized" name matching for linkage to 
connotations?  Is it really harmful if some namespaces appear different at 
a purely syntactic level, even if they actually refer to the same connotations?

#g
--



At 05:17 PM 6/3/00 -0500, Al Gilman wrote:
>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
>

------------
Graham Klyne
(GK@ACM.ORG)

Received on Monday, 5 June 2000 09:03:38 UTC