Lists Home |
Date Index |
- To: "'Bullard, Claude L (Len)'" <email@example.com>, 'Michael Fitzgerald' <firstname.lastname@example.org>
- Subject: RE: [xml-dev] Announce: XML Schema, The W3C's Object-Oriented Des criptions for XML
- From: Mark Feblowitz <email@example.com>
- Date: Fri, 19 Jul 2002 15:41:53 -0400
- Cc: xml-dev <firstname.lastname@example.org>, "Duane Krahn (E-mail)" <email@example.com>, "Satish Ramanathan (E-mail)" <Satish.Ramanathan@mro.com>, "Andrew Warren (E-mail)" <firstname.lastname@example.org>, "Kurt A Kanaskie (Kurt) (E-mail)" <email@example.com>, Mark Feblowitz <firstname.lastname@example.org>, "Michael Rowell (E-mail)" <email@example.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
And, oh, yeah - can namespace help with all of that?
From: Bullard, Claude L (Len) [mailto:firstname.lastname@example.org]
Sent: Friday, July 19, 2002 2:44 PM
To: 'Michael Fitzgerald'
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
From: Michael Fitzgerald [mailto:email@example.com]
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