Re: Uncertainty on xml-dev

At 09:53 AM 2000-06-08 -0400, John Cowan wrote:
>This is a message that just appeared on xml-dev.  I am forwarding it
>here as another indication of the effect of this debate on the
>Real World.  I have stripped identifying marks.
>
>---------- Forwarded message ----------
>Subject: Re: Namespace Question
>
>Today, Somebody wrote:
>
>>I have a few questions.  If I use the "http:" scheme for
>>a namespace name URI, does it not imply that I should be
>>using the HyperText Transfer Protocol?  Yes?    Why or why not?
>
>And Somebody Else replied:
>
>>Three weeks ago I'd have answered "No, it's just a name.  It may look like 
>>a URI, but it isn't really, it's just a uniquely identifying text 
>>string".  I still hope this is the truth.
>>
>>However, there's currently a serious debate [about 1000 emails in the last 
>>two or three weeks] running on more of less this issue on the xml-uri W3C 
>>mailing list.  I think all bets are off for the moment :-(
>
>I submit that this is a Bad Thing.

I agree.

I also submit that there is actual practice (David Carlisle's examples)
where there is no intention of attaching any significance to a namespace.
These are the namspaces where he has used the obvious-garbage URI-reference
"/dev/null" as the ns-attr.  Here the specification bug is that the ns-attr
is a required attribute, not that the value is in relative form.

The use pattern that I am hearing, here, is that the Namespaces in XML
Recommendation syntax is being used in documents where one wants to

a) use markup from some defined language base [e.g. XHTML] as the majority
of the markup in the document


b) use some idiosyncratic markup as well, without definition beyond that
provided in XML 1.0

c) use the standard markup without prefix and hence the idiosyncratic
markup with a prefix.

For this functional intent, a namespace declaration that just declares the
prefix for local use in this document would be sufficient.

I claim as a matter of practicality that this use should be supported.

I would like to reassert that the use of "namespace name" in the Rec. is
misleading and that the semantics intended in the Rec. would be better
identified by the term 'identifying mark' as discussed earlier.

The point is that within the range of semantic patterns that should be
supported, not even this is required in the bounding case.

The substantive problem that I see is that "namespace processing" is
under-defined.  

David Carlisle outlined a scenario where there is one namespace and
multiple schemata and yet more document instances.  If a document is using
markup in conformance with a schema, and that schema employs names used in
divergent schemata, how should the document be processed?

For some processing decisions, it is not safe to process the document in
ignorance of the appropriate schema.  For others, it may be.  We would like
to have a better articulation of the latter class, and "Dear God, let it
include syntax."

What we want is a safe domain of low-level processing where the processing
can proceed without fear of contradiction from the schema, and to have a
reasonable means of asserting constraints in a schema that will come to
bear eventually whithout breaking promises along the way.  Finding a
sufficiently robust and economical way to consisttently map varying
profiles of semantics to "order of processing" is the puzzle.

In other words, I see no way _forward_, as opposed to simple "closing the
relative namespace issue" without some better understanding on the matter
of the order or dependency graph among aspects of processing for polyglot
XML using "some or all of XML 1.1, Namespaces, and schemata."


[Test for consensus:]  So, in terms of a framework agreement, I think we
need a stipulation that all parties agree that for some processing, it is
not appropriate to conduct that processing in ignorance of the provisions
of a pertinent schema if the relationship of some set of elements and
attributes has been established.  This is a long winded way of saying that
the use of the ns-attr for the purposes of comparing across documents or
binding elements and attributes using that namespace to proper processing
is limited, and can be superceded by some stronger indication such as a
normative reference to a schema.

[Test for consensus:]  Something else that should be stipulated is that the
use of the ns-attr as a reference to a schema or other language definition
resource is to be both accepted but discouraged.  Given the history of
confusion, it would be nice to avoid it altogether.  But we can't flat out
deprecate or disallow this because the alternatives are not ready [nor are
the nearly-ready alternatives sufficiently general].  So I guess it needs
to be stipulated that the use of the ns-attr to refer to a document which
give information about the intended usage of these names in this document
is permitted, although more specific means are preferred whenever available.

[Personal note -- not draft framework yet]  Warning:  attributes are too
restrictive and brittle for the general capability to provide references
germane to processing.  The provision of such linking via X-Link and Dublin
Core relationship semantics should be fully explored and opportunities to
extend Dublin Core if deficient should be exhausted before we get into
designing a point solution here.  This also extends to requiring a fixed
syntax for schemas that govern XML or for dialect definition documents that
articulate what in what domains the usage is constrained and the governing
object [schema etc.] per domain as contemplated in the packaging proposals.
 The generic requirements on schemata governing XML usage should be in
terms of the conformability of "the abstract space of points to which the
schema applies constraints" to the XML InfoSet; not the syntax of the
document articulating the corpus of constraints.  This architectural
principle RDF got right, despite whatever integration problems we may have
with using RDF in all its detail as a tool in building XML-based language.

[Test for consensus]:  For the purposes of distinguishing element and
attribute uses in the current document, the scopes and prefixes in the
namspace syntax suffice; even the ns-attr is unnecessary.

[Test for consensus]:  The framework for interoperation of namespaces and
schemas is not well+widely understood, and merits further work.

Open issue:  The problem is in how to craft the statement that the use of
the ns-attr recognition method to compare across documents and bind to
appropriate processing is subject to clarification which may involve
restriction.  That there is a risk that some existing methods of
application could eventually be deprecated depending on the outcome of a
clarification of the interoperation of namespaces and schemas in scenarios
where both are used.

[Warning:]  In the investigation of the interoperation of namespaces and
schemas, the terms 'syntax' and 'lower layer' are prone to misunderstanding
similar to the misunderstandings attendant upon the term 'name' and careful
models will need to be built to replace these terms for the purposes of the
analysis.  This is not to presume that the outcome will meet the Zebra goal
of scoping a consensus small nucleus of lowest-level processing; just that
the space in which one would scope the Zebra will be provided with a
precise map.

Al

Received on Thursday, 8 June 2000 11:42:24 UTC