groves dissent (was RE: RFC: Attributes and XML-RPC)

Tue Sep 28 00:33:35 BST 1999

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 at design-intelligence.com
Ph: 206.343-7797
Fax: 206.343.7750

http://www.design-intelligence.com

> ----------
> From: 	Steven R. Newcomb[SMTP:srn at techno.com]
> Sent: 	Friday, September 24, 1999 9:11 PM
> To: 	xml-dev at ic.ac.uk
> 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 at techno.com  http://www.techno.com  ftp.techno.com
> 
> voice: +1 972 231 4098
> fax    +1 972 994 0087
> pager (150 characters max): srn-page at techno.com
> 
> 3615 Tanner Lane
> Richardson, Texas 75082-2618 USA
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> 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 at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
> 

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)