Re: A little courtesy, please

At 09:51 AM 2000-05-23 -0400, keshlam@us.ibm.com wrote:
>>It is not at all completely obvious how you can say that while
>>also saying:
>>
>>4. It is wrong to compromise the basic utility of namespaces by imposing
>>   strict URI-ness on them
>>
>>5. The use of relative URI references as namespace names is wrong and
>>   dangerous and should be, at the least, deprecated"
>
>The way one says this consistantly is to divide the question.
>
>* Namespaces have utility whether they are bound to URI references or not.
>

How may I, without violating civility, indicate that this is not
universally regarded as an unmixed blessing?  Actually, Simon's approach is
clean in this regard because the actual damage is when namespaced names are
used to control styling directly off the syntactic analysis, with a
guaranteed non-dependence on any sort of schema backing up the names in the
namespace.  This is likely to adversely affect the disability interest.
The architecture should, to the best advantage of the disability interest,
direct styling to the "highest available infoset" for its input, and not
hardwire it to the lower-layer outcome of syntactic processing alone.

>* Such binding may in fact be desirable, but can be achieved in many ways.
>

Absense of such binding may be undesirable as well, see above.

>* Strict URI-ness of namespace names is one such way, but yields
>undesirable behavior of namespaces per se.

The undesirability of the behavior is at issue.  I don't think this is a
critical issue, BTW.  I would be happy simply to say it is good to stick to
our word [Cowan's moral pleas] if we can.  And we can [Simon's layered
application of different sets of rules approach].


>* Switching to another binding mechanism would get us out of this conflict,
>allowing the namespace name to be "just a name" while still allowing the
>name to (indirectly) refer to a web resource. As far as web architecture
>goes, this is equivalent to having the namespace name itself be the
>resource, and so is completely consistant with the architecture... but it
>recognizes that namespace names have their own requirements which URI
>References are not a good match for.
>
>>> So, like, guys, we understand what you're saying.
>>That's not at all clear.
>
>Actually, I think it _is_ pretty clear at this point that folks understand
>that there are conflicting goals. The question is how to reconcile those
>conflicts. We can either break the consistancy of how Namespaces are
>interpreted, break the consistancy of how URIRefs are interpreted, or
>accept that the Namespace name is not itself a URIRef and that the
>Namespace spec was in error when it made that assertion.
>

I still don't buy the "intrinsic conflict of goals" assessment.  It would
appear to me that there are divergent emphasis profiles across shared
goals.  And that the 'pragmatic' short-cuts that have been adopted in
different technology patches: RDF, Namespaces, XSL, -- have in fact
introduced torts or harm to one or another of these goals because the
injured goals were not "uppermost" at the time and among the subset of
stakeholders who were working on that piece of the product at the time.

>>I largely agree with this, but I cannot agree that treating relative
>>URI references as namespace names without absolutizing them is in
>>the spirit of RDF.

What I would like to hear, here, is Simon's description of "what RDF is
trying to do" that we could then test for consensus.  I am concerned that
Dan, just like all the rest of us, may be confusing the details of what RDF
thought was necessary with what is actually necessary to fully realize
"what RDF is trying to do."

For my clients, I am keenly interested that the XML community be more
pro-active in supporting "what RDF is trying to do."  If there are tactical
blunders in RDF as designed that make it hard to get XML and "what RDF is
trying to do" up and running together, I need to know because those clauses
are no more unquestionable in my reading of the moral spreadsheet than is
the literal comparison of ns-attr's.

>How Hard Would It Really Be to say that the absolutization -- or the
>additional retrieval to find the binding to an absolutized URIRef -- is
>RDF's problem, rather than that of the Namespace Name?

The contentious part here is saying "it is not a concern of the 'name'."
The Namespaces Rec separates the space-collected names from semantics in a
potentially dangerous (at least to the disability interest) way.

If, on the other hand, you had posed the question

> 
How Hard Would It Really Be to say that the absolutization -- or the
additional retrieval to find the binding to an absolutized URIRef -- is
upperLayer's problem, rather than that of the syntaxProcessor?

you _should_ get universal, and nearly instant, agreement.  At least you
would more easily get mine.

Al

PS:  This is an actual issue, because when the RDF that applies type-proper
constraint assertions to markup element or attribute types is inline in a
[little-d] XML-document [or XML-module] type definition document [not
necessarily SGML or XML 1.0 DTD compliant, but compatible with instances
conforming to XML 1.0 + Namespaces syntax] it is impossible to say that
processing these constraints is "RDF and not XML."  It is both.

Received on Tuesday, 23 May 2000 11:28:16 UTC