RE: [xml-dev] Announce: XML Schema, The W3C's Object-Oriented Des criptions for XML

[Mark Feblowitz <mfeblowitz@frictionless.com>]

This all makes me think of the relative adaptability of the listener, when
faced with different dialects of the same language. We as human beings are a
good bit better at adapting to variances in dialect than our automated
counterparts. I, for example, as a native Midwest US speaker of English can
understand most accents and dialects (although I have to listen very
attentively to some, and may need a word or phrase translated). 

It's important to note that the dialects are mixtures of different versions
of *the same language* - the same and different intonations, etc.

If our applications were savvy enough to adapt to new dialects, we wouldn't
be having this debate. Apply a Suthun Drawl or a bi' uh Cockney to an
xsl:apply-templates and they'd be fine.

Imagine, though, an XSLT processor handling two different dialects of XSLT.
If told that each version was a new and different language, it would have to
learn the new language to understand it. If told that one was a dialect of
the other, it might at least be able understand most, and to go to a
different source for understanding the new one. 

But we humans are also better at building new pathways for new concepts. We
can not only learn new vocabulary, but can readily intuit in situ meaning
and usage. Try that with a table-based application receiving a new dialect.

Another  problem we're having is that we choose to see the problem as one of
document understanding. I give you a document - if you can understand that
dialect, you can read and understand it. But the problem we in the
interchange world are suffering from is how to coordinate bidirectional
communication in the face of rapid change. That requires, as I've said,
round-trip compatibility, which amounts to version coordination.

The question for us is: how do we best coordinate changes to generation and
interpretation of a dialect, and do so in a way that doesn't require all
interchange parties to pause to learn an entirely new language?

No question that this is Friday Afternoon babble, but I've been seeing so
much heated rhetoric and am yet to feel warmed by it. 

The problem, I guess, goes way past "how should I label my dialect" and
encompasses "how can my various parties adapt to unavoidable changes in
dialect?"

And, oh, yeah - can namespace help with all of that?

Mark


 -----Original Message-----
From: 	Bullard, Claude L (Len) [mailto:clbullar@ingr.com] 
Sent:	Friday, July 19, 2002 2:44 PM
To:	'Michael Fitzgerald'
Cc:	xml-dev
Subject:	RE: [xml-dev] Announce: XML Schema, The W3C's
Object-Oriented Des criptions for XML

Problem is, a coach that doesn't know how and when 
to pick the best players hasn't a prayer of winning.

Does anyone else find it discomfiting that the question 
of version numbers and namespaces was raised some time 
ago and was dismissed without resolution?  We either 
have a lousy learning curve in this community or we 
are very good at postponing proposing a solution to 
a problem until we are a few hundreds yards from 
the iceberg, and even then, momentum affects outcomes.

Not to pick on either of you, but this is illuminating 
when posted on the same day:

Rick Jeliffe:  " All a namespace does is set general semantics."

David Carlisle: "Namespaces are not about semantics they are about names."

I know the arguments on each side of this.  It still comes down 
to expectations of interpretive communities.  The lack of 
consistent observable behavior given two interpretations of 
the same code system is the classic definition of the failure 
to communicate.   I think it time to put away the distraction 
that something with a protocol morph appended to the front 
of it is just a name.  That is irrelevant if the framework 
does not give the author a choice about the operator that 
can be applied to any value with that name.

I really don't care if one does or does not dereference a 
namespace value.  It is useful to do that and obvious.  I 
do care that given one, I cannot divine the intent.  That's 
just dumb design.  SGML avoided it.  The WWW embraces it 
like hemlock and expects everyone else to.  Dumb.  Just dumb.

URI != URL.  An abstraction that leads to an ambiguity of 
this type simply isn't useful globally.  It is as if one 
is programming in a language that requires all variables 
to be declared in scope and forgets  that every use 
of i in a for loop increment stomps every other use of it. 

j != i

len

From: Michael Fitzgerald [mailto:mike@wyeast.net]

Delayed reply:

Other lessons are that XML and related specs must evolve and that the best
players don't always get picked and as Knute Rockne said "Prayer always
works better best when you have big players" (paraphrase).

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>