Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Proposal for src files
 At 08:51 AM 4/2/98, Peter Murray-Rust wrote: >At 11:22 01/04/98 -0600, W. Eliot Kimber wrote: > >>But maybe I'm just a crank. > >No. But you have a level of vision and understanding that makes it >difficult for others like me to follow. This is a recurring theme in the >whole of current IT/CS - there are 'right' solutions that people simply >are not able to comprehend or find too difficult to adopt. In those cases >one ends up with a small number of people who provide a solution (often at >high cost) to a large number of people who don't understand an don't own >it. IMO the single most important thing about XML is that it makes things >accessible to at least a hundred times more people than other technologies. >We are seeing this debate frequently now - 'what does XML do that XYZ >doesn't?' My answer is that it can relate to ordinary hackers - and >possibly even to inspired management. I certainly appreciate Peter's comments here--he's 100% correct. The distinction I try to make is this: a relatively small number of enterprises have serious problems that can only be solved by things like full SGML, the whole of the HyTime standard, the DSSSL transformation language, and other "big" solutions to hard problems. That's the environment I like to work in. But not everyone needs this level of solution. Thus XML and its related specifications. At the same time, I know that most enterprises' challenges are more involved then they may think or may want to admit, which means that in many cases, the simpler solutions provided by XML will not be sufficient, which means that they'll need to start using some parts of the more complete solutions--not all of them, just those parts they need. The challenge is to bridge the conceptual gap between the entry level of XML and the full solution provided by the big standards. I certainly agree that saying "just read ISO/IEC 10744" is not a productive way to do it. But the problems are real, solutions have been thought out and, to some degree, implemented already, so there is value there once you're ready to go get it. But until you're ready, it's just noise. I appreciate that. I see my job as helping people to bridge that gap. I think the real problem is that complex information management challenges are complex--there are no simple solutions. Complexity conserves. The best you can do is concentrate the complexity so that it can be hidden from those who are not responsible for managing it. But the complexity has to go somewhere. Look at automobiles. Twenty years ago, anyone who could read could fix their new car--all it took was a shop manual, a few tools, and some patience. Cars were simple, but they failed to address a number of problems, like fuel efficiency, safety, emissions. They needed to be tuned every few thousand miles. Today, you cannot do more than change your oil unless you are a factory-trained mechanic with lots of expensive tools. But cars are much more fuel efficient, safe, and clean. They can go 50 or 100 thousand miles without a tune up. The complexity has been concentrated where before it was distributed. There's a place for both. I have a car I can fix and car I can't. I use HTML for quick fun and full SGML for more involved fun. I wouldn't drive across the country in my MGB and I wouldn't entrust my business-critical data to HTML. >>except in the most trivial way (a direct transliteration of DTD syntax) > >I was thinking of something very trivial (you didn't expect anything else >from me, surely :-) - a lossless translation of DTD to XML format (and vice >versa) without any inheritance, mapping, etc. I thought this was >uncontroversial - but maybe I haven't got my point over. >>unless it is *explicitly* defined as a base architecture with very clear >>rules for specialization. And even then, developing that architecture will >>be difficult at best. >> >>The reason it's practically impossible is because getting agreement among a >>community of interest as wide and varried as the XML community on a subject >>of such importance as how to represent the definitions of document types is >>one of the hardest types of things there is to do. There are simply too > >I wasn't trying to tackle this. We already *have* a definition of document >types - it's XML 1.0. I was simply suggesting we standardised an XML-based >syntactic representation of this. Ah. My point is that, if that's all it is, why bother? If you can parse DTDs sufficiently to generate XML versions, why bother generating the XML version? You've already parsed the thing the data's already yours to manipulate. If you do want the XML version, then go back into the c.t.s archives and find Wayne Wohler's posting (I'm sure he posted something about it). In any case, it's a pretty obvious design effort and the result should be uncontroversial except for some arbitrary design choices (use attributes? etc.). >>The minimum abstractions needed to define element types are already defined >>by the SGML property set--if your schema language can get you to these >>abstractions, fine. > >Perhaps all we need is a representation of the property set in XML format. >Would *that* be controversial? I've created it. Check out "http://www.hytime.org/materials/hi2pssgm.xml" (created from the SGML property set definition document published in ISO/IEC 10744 using SX). I believe there is work to define an XML-specific version of the property set that is organized and presented in a way that is more appropriate for the XML audience (I would not, by any stretch, pretend that the property set document is an accessible document as currently formulated--it's very useful as a formal specification, not too useful as a tutorial introduction to the SGML data abstraction.). However, a tree view of the document goes a long way toward making it easier to work with. I'm developing a tool that will, among other things, provide navigable tree views of property set documents. Watch this space. I also appreciate Tim's disagreement with my position. It is a subject on which reasonable people can disagree [I'm reminded here of the excellent childrens' book *The Phantom Tollbooth*, where the main character does the impossible because no-one told him he couldn't do it.]. If the effort succeeds, that's good. But my experience suggests that it's going to be a lot harder than it might look at first. I also feel that it's too early in the day to start standardizing--we need more experience. There's a lot of good thinking on schemas in general that needs to be examined and synthesized. Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
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
|
|||||||||
