[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: loosely and tightly coupled systems and type annota tion
The problem is, they aren't interoperable. They are just portable. And without strong typing, a database isn't terribly efficient. One might want to stop and ask about XML databases and does one really need them. If one stops with "XML will be applied as a serialization", one can get away with that. Sick though ye may be, that's markup. You can't have it both ways. The specs are not XML except for XML 1.0. That's core. The specs can be as huge and crappy as people want to make them. XML Doesn't Care, so a defense or an attack based on them that says "that ain't XML" is both correct and irrelevant. SGML didn't allow one to build their own markup structures in the sense that just like XML 1.0, ISO 8879 was the whole of the law for SGML itself. Yes, it had more options, true, but also irrelevant. That was fixed when XML 1.0 was released. This isn't ISO 8879 being discussed here and yet another "we'll blame SGML" argument is just noise. This is the XML subset of SGML being discussed. Now, where are your problems starting? Not in XML, but in these "crappy" specs as you say. 1. If you don't need XQuery, XSD, etc., don't use them. 2. If those who need them build them, you have no complaint. That's their choice. 3. If those you need to work with require them you can a) Explain what the problems are to those people in terms of those requirements b) Not work with those who need them c) Offer alternatives to meet those requirements. One can't stop the W3C or any other organization or individual from exercising their right to build applications and systems using XML. One can rightfully resist their claims that these applications and systems are essential parts of XML. They aren't any more than a MS Word is a rightful part of C++. It comes down to choices, quality of choices, and who chooses. Right now, the WWW architecture is decided by the TAG and the voting members of the W3C. The Internet is a bigger domain. The W3C could resist SML but could not stop it. The SML group could create SML but also had the responsibility to sell it. They could not claim it was XML. Again, one can't have it both ways. That's simple enough. My worry is when some bozo in charge decides that: 1. Only W3C specifications will be acceptable without reference to merit or application. 2. Members here and elsewhere applaud a decision like that. That's technical groupyism. 3. We have to support it because it shows up in an RFP and therefore, closes the circle of "crappy" specs normatively referencing "crappy" specs. At that point, we all end up with redder noses and overinflated shoes. I don't mind being wrong; I can learn. I mind being right and irrelevant. len -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] > As long as that core remains untouched, all of the debates > on loose and tight coupling, schemas, strong typing vs > lexical and structural named types, are simply and > only choices of the application engineer. I have to admit that I'm incredibly sick of the "don't worry about how huge and crappy the specs are - the application engineer just gets to pick and choose the parts they want to use." I thought we'd gotten past this hurdle when XML discarded all the optional bits of SGML, rejecting the build-your-own-markup-structures options in favor of creating systems that could be widely shared and interoperable without profound and tedious negotiation. XML 1.0 by itself seems to have been designed to avoid the need for such negotiation, reducing the level of coupling needed to build useful applications substantially at the outset. As we move "forward", that lesson appears to be getting utterly lost under a huge pile of features, and now we have to negotiate all that crap yet again just to share files. Coming up with vocabularies is difficult enough without having to choose from the feature set of "Greater XML". Expecting that these extra features won't make that process even more difficult over time seems blissfully naive. If every application engineer was an island, I'd give this theory a tiny bit of credibility. As very few XML application engineers have that luxury, I think it's time to stop pretending that Greater XML can be ordered a la carte.
|
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
|