OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] loosely and tightly coupled systems and type annota tion

[ Lists Home | Date Index | Thread Index ]


Bullard, Claude L (Len) wrote:

> I realize that, but I've never been able to 
> find a way to stop a stampeding herd.  If it 
> is following a leader, then at least that 
> is the person who's direction can be changed.

Continuing the analogy, there are two problems with that approach. The 
first is that by the time you've worked your way through the herd, 
(reasoning your way past all of the others who believe just as 
passionately in their own views) and convinced the lead buffalo that 
you're right and it's wrong, you may find yourself girt by sea.

The second problem is that although even the lead buffalo believes that 
it's leading a single unified herd, in this case it's actually a number 
of smaller herdlettes running together. Each herdlette has it's own less 
obvious leader steering a portion of the group in a slightly different 
direction. For those common herdmembers who are certain of whom they 
wish to follow, this isn't an issue. For some though, the choice is less 
obvious, resulting in confusion and fragmenting of the whole along 
specific and predictable lines.

> The W3C has a Director.  At various times, I 
> have come down hard on that position, but an 
> honest fellow holds it.  Start there.  

I don't think anyone's questioning his honesty. The point is that the 
more diverse the uses for XML are, the less anyone can claim to have a 
comprehensive grasp on it. This is particularly true when the evolution 
impacts on a field outside one's own experience. Unless TimBL has a 
capacity unmatched by anyone that I know, he will be relying more on the 
opinions of others than he used to. That means that if we see a trend 
toward a direction that we don't agree with, we should speak up, making 
it easier for him.

> What technical requirements have lead to the 
> complex morass of interlocking specifications?

You'd have to define "technical requirements". I think that the problem 
is that XML is being pulled in different directions. Some features could 
be defined as technical requirements of the industry doing the pulling, 
but I'm not sure that you can call them "technical requirements of XML". 
I'd classify them more as "useful features for a specific profile of XML".

> Stew left to stew goes bad fast.

Ahh, at last, the inevitable fate of the herd...;-)

Stew made with my favourite ten foods smells bad as soon as it hits the
heat. Perhaps it's the tunafish reacting with the milkshake. It's hard
to fathom though, when they're both such fine foods in their own rights...


-- 
Regards,

Marcus Carr                      email:  mcarr@allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
        - Einstein





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS