[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Where does the "nothing left but toolkits" myth come f
The problem with writing to a news-list is that good arguments can often sneak in under the radar as you're writing your response. If you remove DTDs, you still need to have some mechanism that replaces those DTDs with something else. XSD don't hack it - its singularly poor at expressing those very things that people keep using DTDs for. Relax-NG is a little closer, and personally would be superior to both XSD and DTDs in that regard, especially once you provide an alternate mechanism for entities. I would be VERY careful about playing with preprocessors. I think this was one of the problems that caused problems for both SGML and XML in the first place. I have an intrinsic distrust of processing instructions, as they by their very nature reduce portability of XML. This has always been something that's bothered me about Microsoft markup in particular - they LIKE PIs, even as the rest of the world seems to have moved away from them. I also think that for all that I would love to see CDATA sections become ancient history, they are necessary - simply because a CDATA section can (pretty safely) encapsulate text that has syntactical markup, something that will be true regardless of what symbols are used for denoting that section. I should also point out that CDATA sections become almost necessary when dealing with "unsafe" content - XML wrappers holding blog feedbacks written by people who don't have the first clue about why ampersands in text are bad for your application, or for situations where you don't WISH for your XML to be interpreted (such as examples given in a textbook). CDATA exists because you need to have a way of escaping content from interpretation. Several years ago, there was a movement to "simplify" XML, with a lot of mud being slung on both sides. Significantly, after a while, the argument died away, because of the realization that any simplification of XML reduced its use for others who found their core needs no longer met. I think that by forking XML yet again, you run the risk of marginalizing yourself with a use case that buys you some efficiency gain for a limited set of applications at the cost of reducing flexibility, despite the fact that it is that very flexibility that makes XML so attractive for such a wide number of use cases. On Sun, 6 Feb 2005 12:51:15 -0500, Michael Champion <michaelc.champion@g...> wrote: > On Sun, 06 Feb 2005 08:47:32 -0700, Uche Ogbuji > <Uche.Ogbuji@f...> wrote: > > > > > > If you insist on this "hand-written XML is obsolete" theory enough to > > use it as a case for focusing XML 2.0 on toolkits, you're going to have > > to come up with a lot of evidence to back up your dubious claim. > > I didn't say "obsolete", I said it's not the mainstream use case for > XML I see. XML 1.0 appears to have included a lot of stuff to make > it easier to hand author, and in my non-expert opinion is that stuff > seems to be causing a disproportionate amount of the pain for > developers. I'm not presenting that as a conclusion that I wish to > defend, just a reason for being interested in a profile of XML that is > focused more on the feature that are most valuable to the mainstream. > > The point that hand-authored XML may be a small percentage of the > volume but it is more important as assets in the typical system is a > very interesting one that I'll have to think about. I wouldn't even > begin to dispute that this was true in the early days, but I think XML > is pretty well bootstrapped now. The text format that allows "hand" > tweaking and debugging is definitely a key part of XML's value, but > that's not what I'm talking about. > > My personal preference (really a best guess, since I haven't tried to > really design or prototype it) would be to remove DTDs and maybe some > other bits such as the highly confusing whitespace rules, CDATA > sections ... out of the XML *core* and put them in some spec that > governs what a preprocessor would do to turn that syntax sugar into > the minimized core syntax, e.g. translate character entities into > Unicode, escape the individual characters that need to be escaped > inside a CDATA section, etc. I have no desire to make the syntax sugar > obsolete, I just don't see a long-term value for baking it into the > very core of what XML is. People who find that stuff useful for > hand-authoring or vendors who need backwards compatibility with SGML > and XML 1.x can stick with it, fine with me, they just would have to > use the preprocessor along with a hypothetical "XML--" processor in > their work. > > Again, I don't really know if this would improve the REAL value of XML > or just its geek appeal to me. I think that's an open question, and I > freely admit that we all have different takes on this from our work > experience. The reason I babble about this is to stimulate feedback > from others so as to get a balanced perspective. > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://www.oasis-open.org/mlmanage/index.php> > > -- Kurt Cagle http://www.understandingxml.com
|
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
|