Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SML: Second Try
 It's pretty easy to discriminate SOAP from DOCBOOK. Read the specs for the applications. Don't make the spec for the metalanguage take on that role. Who pounded entities and DTDs into SOAP? Not moi. Instead, they sensibly excluded them just as the IADS group sensibly excluded DTDs and used stylesheets for SGML without needing XML to tell them how to do well-formedness. The only rub was having SGML wonks beat them up for doing in 1991 what the rest of the world would call XML six years later. So? Are the XMLers beating up the SOAP folks? No. It seems the other way around this time. The rest of what you are saying is more of the same: fear of the wild. That is, if we don't make an official subset, subsets will grow willy-nilly. So? Are we here to protect a "brand name" or to ensure that XML 1.0, 1.1, are inclusive? I don't dispute that a subset can be devised. I think the XML-SW is such a device. I haven't seen a requirement for it other than tidy documentation of some intersection of common practice which if normative, gives a bit to some, but takes a bit from everyone. The intersection that is broken are things like ids. That is, it is as we have known for years not possible to completely separate processing from declaration. Not new news. Sure, the same was said for SGML and in the large it was true. Easier to understand is easier to sell. But XML is already implemented widely so why do this exercise again? SGML had features that were designed for an era of less convergence. It was also more author friendly, but at the cost of tool complexity thus, tool cost. Authors gave up some conveniences (eg, minimization) to make it more attractive to a narrow but influential group: programmers. The trade-off created an environment that produced more and cheaper tools. I don't see that tradeoff happening here. I see a narrow application trying to make its own performance an issue for every user. That is, as David Durand used to remind us, an issue of implementation, not design. len From: Mike Champion [mailto:mc@x...] On Mon, 10 Feb 2003 09:57:26 -0600, Bullard, Claude L (Len) <clbullar@i...> wrote: > > SOAP works. What about XML 1.0 keeps SOAP from working? > XML binaries are working. What about XML 1.0 prevents that? Nothing! Web services don't need anything different from XML, they just took what they needed. XML binary users don't care that what they're doing is anathema to some XML geeks. IMHO, XML needs to be concerned about these things for its own sake, not the sake of diverse communities of users. The question is whether "XML" will mean anything as a brand/label after another 5 years of this success. It might become about as meaningful as "LISP" or "SQL" (without qualifiers) -- a generic term describing a general approach, but not anything that interoperates out of the box. The way forward that I suggest is continuous refactoring to keep the Core "core" and the de-facto optional parts separated. I don't want the data-heads to drive static typing into the core to the detriment of the docheads, but neither do I want the dochead stuff such as entities to be inflicted on the data-heads now that the costs are becoming apparent. The SOAP people aren't harmed by simply ignoring DTDs, but XML is harmed if there is no formal way to distinguish "XML as practiced by SOAP" from "XML as practiced by Docbook". 
|
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
|
|||||||||
