where's the beef?

At 02:45 PM 2000-05-19 -0400, keshlam@us.ibm.com wrote:
>
>If the phrase "URI References" had been replaced by  "strings in URI
>Reference syntax," it would have said exactly what it meant to say.
>
>Unfortunately that's not what some folks feel should have been intended.
>

Let me confess to being one of those that feels he was hoodwinked.

Not on the above point.  I actually grasped that.  I misunderstood the
intent of the drafters on a far grosser scale.

When the Namespaces Rec. went forward through last call, I failed to move
to block it only because I misunderstood the scope of the "literal
comparison" clause and the "not an intent to.." language about discovery of
schemas or other documentation about the names in said namespace.

I was under the mistaken impression that the literal comparison criterion
was only defined as the definitive method for function #1: disambiguating
names in the local context of the current document.  I failed to realize
that the framers intended this to be the exact and global solution for
function #2: comparing names across documents and associating document
markup with appropriate processing.  The "no intent to imply any recovery"
language I conveniently read as applying to the syntax introduced in the
current document and the local-name-disambiguation function attached to
that syntax by the current document; not a general statement about
namespaces in the large or in perpetuity.  So much did I misunderstand the
intent of the framers.

In retrospect, I believe that the Working Group overreached if they thought
to provide for _all_ cases of "associating document markup with appropriate
processing" by the literal string comparison method.  That is to say, the
syntax should not be bound to semantics that is that restrictive [apologies
to Walter].  This may have been an overreaction to what they in turn
perceived as a W3C staff over-emphasis on RDF and schemas.  In fact, the
discussion since has led to [as I understand it] general agreement that
"applications may" dereference the namespace URI-reference and may do
things with what this yields.  I am not equally comfortable that there is
mutual agreement on the more subtle question of whether the 'applications'
in this clause are unique processors on unique net nodes as per Walter, or
abstract applications, each of which is a class of distributed processors
homogeneously conforming to some set of constraints published in
association with the names in the namespace.

It is, however, better to leave the flexibility in the system that there
are some namespaces which are defined as the index space of a
guaranteed-unstable domain and _require_ retrieval of resources for their
processing just as much as there are [many more] namespaces where the
definition of the namespace is highly stable and routinely processed
correctly without recourse to any recovery action.  


Stability, globality, and formality of semantics are in practice a matter
of degree and gradual technological and societal progress.  Not something
for which it is feasible to declare by fiat that XML namespaces shall
themselves form one, global, flat and eternal namespace and that's that.
You don't get namespaces to be global and stable by saying they have to be.
 You do it by a lot of hard work invested in hard choices in crafting
definitions attached to the names.

The corpus of specifications for namespace use in XML should be migrated
into a state where it is clear that "globally unique and stable" namespace
definitions are highly desirable, but not assumed.  It is neither necessary
nor appropriate to outlaw the transient or local cases to maximize the
contribution from the use of stable definitions and global names.
Stability of a namespace should be one of the things you know about some of
the namespaces you know, not something you can infer from the fact that the
namespace has been declared in an XML document instance.  Processing based
on recognition of the literal text of the ns-attr should be contingent on
independent knowledge of stability for that namespace, not presumed from
the namespace syntax.

Local-use namespaces which employ relative-URI ns-attrs do not need to be
deprecated except out of a misguided purity principle for namespaces.
Since the Namespaces Rec. provides no effective mechanism to provide 100%
globally unique identifiers, anyway, it should not act as though correct
namespace use is predicated on this unachievable goal [May I second Larry's
remarks about practice =/= theory...].

In the straw poll I voted that absolutizing was prefered, but literal
comparison was acceptable.  That is how we in the WAI roughly saw the
impact on the interests of accessibility for people with disabilities [no
formal vote, but one round of for-comment exposure in a hurry...].  These
interests _are_, however, critically dependent on the evolution to stronger
shared models of "common knowledge associated with a markup vocuabulary
which may be attached to using a namespace declaration." [refer to my
earlier post about table semantics.]


The working assessment of the WAI is that the disability-interest
reasonable accomodation requirements _can_ be fully met by the
schema-location information item defined by the XML Schemas drafts, and
other similar linkage capabilities, without any _necessary_ use of the
ns-attr as a recovery key.  So far as we have been able to discern, using a
server address and an URL to be the URI-reference in a namespace
declaration is not a universal fit to all requirements, as others have
commented here.  It is a good practice in some simple cases, just because
it eliminates steps of indirection where they can be eliminated.

I would certainly consider changing position that absolutizing may not be
the best choice overall, after hearing some of the discussion here.  But I
believe that the highest and best outcome is that we would descope the
application of the literal comparison to a) disambiguation in the local
document scope and b) a shortcut that people are advised to make work if
they want processors to be able to get on with the job without further ado.
 It should not be "required" or assumed that all namespaces in XML are so
processable.

It has been suggested that "you can never get agreement on requirements."
I don't believe that.  Very often getting agreement on requirements takes
longer.  Coming to regret your past actions can take longer this way, too.

Part of the point here is that there was a de_jure process commitement to
some language in the "Namespaces in XML Recommendation" which _ex post
facto_ we have to realize did not enjoy as much consensus as one might have
thought.

If the "URIs are URIs, dammit" camp can just accept the literal comparison
as the appropriate shortcut processing, and the literalists can just accept
that this processing may have to be backed up with dereferencing the
namespace URI or some other URI-form link in occasional cases _to identify
appropriate processing, not to disambiguate tokens_, I would go home very
happy.  This would, incidentally but not critically, allow relative
URI-references for namespaces of temporary or local applicability to be
included in the supported range of use.

Maybe then we could move on to addressing more substantive topics as to how
we back up mix and match namespaces with effective levels of semantics etc.

Al

Received on Friday, 19 May 2000 16:46:15 UTC