[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Announce: XML Schema, The W3C's Object-Oriented Des cripti
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@i...] Sent: Friday, July 19, 2002 2:44 PM To: 'Michael Fitzgerald' Cc: xml-dev Subject: RE: 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@w...] 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>
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|