xml-dev - Re: The Power of Groves

[Len Bullard <cbullard@hiwaay.net>]

Peter Murray-Rust wrote:
> 
> At 07:25 PM 2/9/00 -0600, Len Bullard wrote:
> >W. Eliot Kimber wrote:
> >>
> >
> >I am *abusing* Eliot a little here because we need to have some
> >better understandings in our community and this is an example
> >of how easy the misunderstandings perpetuate, and in the rapid
> >feedback of lists to lists to lists, amplify.
> 
> I don't think we should abuse anyone on this list - we have a common
> challenge here that is very tough and we need all our resources!

A tease, Peter.   Eliot and I have done this before.  Facts are hard. 
We did do a lot of work on the PDES/STEP community prior to the current 
effort.  Things do get reinvented.  Funds go away.  But mainly, we 
are no longer subject to some of those restrictions and we can 
take advantage of it.  Eliot has been helping me and 
others with Hytime and other issues since comp-text-sgml. 
As in debates in the schools of England, some rhetoric is 
to position later positions.  Be assured I like the ragged rascal 
and respect him enormously.  :-)

> Groves are hard for people like me because they are abstract. 

And by working examples, current problems, and pending opportunities, 
this thread is devoted to changing that by showing they aren't 
that abstract, they are just named weirdly.  But also, we must 
establish by example, just how useful they can be to overcoming 
some of the barriers rising from the overlapping authorities and 
the very medium we work in that amplifies and exaggerates differences 
while sometimes glossing over huge real problems.  Standards are 
very tough work.

> Perhaps JamesC's posting (I am offline so cannot pinpoint it) is a starting
> point.

A list of resources is good.  Again, Robin keeps up with a lot of this.  
What interests me at this juncture is how groves might be applied 
not just to the new application languages, but also where we have 
to handle multiple encodings.  If the outcome is, not really useful, 
then we are a bit further along.

> I do, however, recall an analysis by Henry Thompson of the complete grove
> diagram of a very simple XML file with 1-2 elements types and attributes
> and including a DTD and it was surprisingly complex. I don't think it was
> on this list - probably XML-SIG. Groves are not trivial.

Hmm.  The data point is, they are complex to apply, or are they?  

> Nothing must go behind closed doors

Well... band rehearsals and novice violinists come to mind.

> Agreed. This is what henry and I devoted our time to.

And you did well. Consider it a karmic coupon for the 
next round. :-)

> The problem for groves is marketing, 

Not yet. The problem first is for us to prove to ourselves 
and the rest of the list the utility.  The way is to use 
them and apply them here in examples until we are all 
conversant.  Until there is an AHA from the rest of the 
markup community, then our biggest problem is the obscurity 
of the descriptions.  SGML was once treated in the same 
light.  As long as we dealt exclusively in the language 
of generic identifiers, notation declarations, document 
type definitions, top-forward parsing, and so forth, 
the language of The SGML Way, we lost a lot of ground.  
Standards are written that way for a reason.  Selah, 
but as soon as we relaxed and quit beating people up 
for saying "tagname", we got a bit further.  We need a 
slightly relaxed and intuitive parlance for open 
discussions.  We don't have to invent groves.  That's 
done.  We want to apply them.  If we can get that 
AHA, using the fifty word or less descriptions, we 
have a shot at that.

> and for that we need critical mass or
> people, tools, tutorials and demonstrators. My problem with all of this
> area (groves, hyTime, AFs) is that although I can see it is a coherent and
> consistent way to do things it is a lot of effort to take on board. 

And a diamond is a bitch to shape but the results are better
than zirconium.  Trust me, I've been dragging this sled a while and 
am tired, but there is this really good slope, well-packed snow, 
maybe a busted head or maybe a fantastic ride.  We should try 
or move over and let the kids do it while we hang out around 
the fire.  Moreover, I am deeply concerned that as the web 
continues to get harder to build for, we will lose something 
we need:  new blood, artistic talent, worthy art, all because 
we made it too damm hard.  Then the artists have no recourse 
but to surrender to the Sonys and Microsofts of the world 
who will give them all the candy they can eat as long as 
they send the coupons back.

> Part of
> our problem is that XML syntax is easy - especially because of its
> resemblance to HTML. The fundamental architectural problems are hidden, and
> difficult. Unless there are portable tools which use these concepts and
> which present a relatively coherent way forward, the Desperate XML Hacker
> is going to invent their own - on the fly - and end up in the tarpits. I
> agree it's a chicken and egg process.

The problem is, even the mythical Desperate hacker is a level above many 
who can otherwise do brilliant work if they don't have to be distracted 
by the technology or surrender their life's work to the tool makers.
The credo of SGML was to free information from guys like us 
(to paraphrase the good doctor).  I still think it the right way.

len