[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: groves dissent (was RE: RFC: Attributes and XML-RPC)
It seems amazing that it is difficult to grasp that namespaces and aqrchitectures have little in common: 1. Namespaces handle ambiguity: the same name means different things. <a> has more than one meaning hence <foo:a> and <bar:a> 2. Architectures handle synonyms: There are alternative names that mean the same <a> really means <b> under architecture B and <c> under architecture C. There's a big difference between ambiguity and aliasing. For why both architectures and namespaces have problems with DTD re-use and mutliple applications, I refer to my Markup 98 paper - www.designintelligence/media/xml98.pdf Marc B. McDonald Principal Software Scientist Design Intelligence, Inc. 1111 Third Avenue, Suite 1500 Seattle, WA 98101 marc.mcdonald@d... Ph: 206.343-7797 Fax: 206.343.7750 http://www.design-intelligence.com > ---------- > From: Steven R. Newcomb[SMTP:srn@t...] > Sent: Friday, September 24, 1999 9:11 PM > To: xml-dev@i... > Subject: Re: groves dissent (was RE: RFC: Attributes and XML-RPC) > > [Matthew Gertner:] > > ... HyTime throws out too many hard-to-understand concepts at > > once. The linking model is hard to understand. Groves are hard to > > understand. Architectural forms are hard to understand. Throwing > > these together in a 1000 page document is not a recipe for > > commercial success. It seems to be an unambiguously good thing that > > these concepts are now being split into bite-sized chunks in the > > process of transfering them into an XML context. > > I have no choice but to agree with you (and believe me, it has been > difficult for me to stomach this particular reality). I *would* > rather have it all broken into bite-sized chunks, if that's what it > takes. I only hope we can put Humpty Dumpty back together again > later. (By "Humpty Dumpty" I mean the meticulous balance with which > all the concepts of component addressing, re-use, and semantic > assignment fit together seamlessly, consistently, and with minimum > implementational redundancy in the HyTime family of information > architectures.) > > Indeed, the problems I have with XML Namespaces all have to do with > the fact that there are ways of using XML Namespaces that will create > unnecessary -- and maybe even insuperable -- difficulties for those > who will have to put Humpty back together again. XML namespaces, as > presently defined, are widely (and perhaps unconsciously) regarded as > meeting the same requirements that the architectural forms paradigm > (inheritable DTDs) already meets. Some Very Influential People at W3C > are on public record as believing/expecting XML namespaces to meet the > same requirements that are met by the architectural forms paradigm, > even though the Namespace Rec correctly makes no claims that Namespace > paradigm can meet any of the same requirements that the architectural > forms paradigm meets. > > Architectural forms, which are presently formally representable only > via the hoary and suboptimal (but at least standard) DTD syntax, *do* > meet those requirements. Architectural forms already work perfectly > with XML, as I demonstrated last February at XTech 1999, and as Eliot > Kimber and others described at Metastructures 1999 last August in > Montreal. > > In my public speaking lately, I've been urging all my listeners to > pray for the XML Schemas committee, which has a very hard job to do, > and which is trying to do it under circumstances which are, well, > trying. Although I am not privy to the discussions in that committee, > I detect stronger and stronger linkage between XML Schemas and XML > Namespaces in the information that W3C chooses to publish about that > project. If XML Schemas only affect XML Namespaces, or if they are > totally dependent on XML Namespaces... well, I don't like to think > about it. Many systems and industries will stick with DTDs and > architectural forms, because they work. Architectural forms allow the > "finger of blame" (for failures of information interchange) to be > pointed, even when there is local control of the DTD, and they allow > all elements and attributes to have any names at all, while still > being automatically recognized as architectural forms. Anyway, I'm > still hoping that the XML Schemas committee > > * will act favorably on its recognition of the importance of being > able to validate the use of vocabularies in instances, > > * will harmonize all the concepts of DTDs, namespaces, and inheritable > architectures in XML Schemas, creating a single schema syntax that > will accomplish that goal, so we can say good-bye to DTD syntax at > last, and start using something much richer, much more convenient, > and much more helpful in promoting the reliability of information > interchange in a system-vendor-neutral fashion, and in a > multi-system-vendor environment. > > It may not be easy to design that syntax, but I see no technical > reason why it's not doable. It's also pretty obvious that the schema > language itself should be formally modeled and expressed in its own > syntax. (On the way to that goal, some bootstrap problems can be > solved by using the old DTD syntax.) > > I believe that Paul Prescod's "Hedge Automata" presentation at > Metastructures 1999 should be well-understood by whoever's trying to > design the long-awaited XML Schemas recommendation. There is hope > that the formal expressions of architectures (vocabularies) can be > validated for conformance to their base architectures (their inherited > vocabularies). The ISO architectural forms paradigm only permits > *instances* to be validated against their base architectures > (inherited vocabularies), not *DTDs*. While this is not a weakness > that diminishes the usefulness of architectural forms, it would be > very nice to be able to validate the formal expressions (such as DTDs > or other schemas) of architectures against the formal expressions of > the architectures that they declare themselves to be based on. For > example, it would allow people who are trying to design DTDs that > declare themselves to inherit from one or more base architectures to > have a tool that will detect inconsistencies between the DTD that they > are writing, and the base architectures from which they wish to > inherit certain architectural forms. > > > (BTW: I have to make a big plug for Paul Prescod's July99 grove > > tutorial. After reading this I *finally* feel like I understand what > > the #%@$! a grove is. Great work Paul! If you are trying to > > understand groves without reading this, don't torture yourself.) > > Good advice. Paul's tutorial can be found at > http://www.prescod.net/groves/shorttut/. > > -Steve > > -- > Steven R. Newcomb, President, TechnoTeacher, Inc. > srn@t... http://www.techno.com ftp.techno.com > > voice: +1 972 231 4098 > fax +1 972 994 0087 > pager (150 characters max): srn-page@t... > > 3615 Tanner Lane > Richardson, Texas 75082-2618 USA > > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... > Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on > CD-ROM/ISBN 981-02-3594-1 > To (un)subscribe, mailto:majordomo@i... the following message; > (un)subscribe xml-dev > To subscribe to the digests, mailto:majordomo@i... the following > message; > subscribe xml-dev-digest > List coordinator, Henry Rzepa (mailto:rzepa@i...) > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|