[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The Power of Groves
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
|
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
|