Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: Peter Murray-Rust <email@example.com>
- Date: Thu, 10 Feb 2000 18:51:44 -0600
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
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.