[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Symbol Grounding and Running Code: Is XML Really E xtens
From: Simon St.Laurent [mailto:simonstl@s...] clbullar@i... (Bullard, Claude L (Len)) writes: >>We don't have to pretend to globally agree. Some >>set of people can, however, agree. That is standardization. >There are lots of varieties of standardization. I think the path you're >seeking is way out on the overreach end. Not at all. Citing a standard normatively in a contract is a normal business process. It is legally binding. Done all the time. Darn hard to process sometimes because when we go to read the standard to figure out what it obligates us to, we find holes bigger than Dubya's ego and just as tough to live with. >>We are facing increasingly difficult problems with >>IP. One approach to damping that problem is royalty >>free standards. Would you say that is not a productive >>or as Tim said, a substantially better situation? >If someone's going to patent ways of interpreting markup based on >namespaces and gets/enforces that patent, we're screwed in ways that a >standard isn't going to help. Yes. That won't stop them from doing it. It means higher costs to fight that. Better to standardize it in a IP-declared, royalty-free standard. Remember the Nielsen patent? >On the bright side, that might finally abolish namespaces. I doubt it but it will make the standards committees take a lot more care about not leaving holes they can't vouchsafe. If the vendors such as Microsoft and Red Hat begin to understand the value of this, they will slow down and do it right. One tactic will be that when an issue can't be resolved, that feature is left out. It will help. >>I can't go down a path where 'everyone does their >>own thing with the markup'. >You do. You're on it. It's only through the kindness of others and >similarity of purpose that we have as much commonality as we do. No d'oh. Problem is, the middle vendors, people who build systems based on that EULAized or GPLized code DO have to indemnify it. Here's the deal, my darlings: we will soon refuse to accept your risks and your precocious but adolescent approach to risk management. ANY vendor of core technology that steps up to the responsibility of indemnifying their products to us such that we only have to indemnify our applications of it GETS OUR BUSINESS. GPL and EULA be dammed. If MS can figure out how to do that, fine. They win. If Red Hat can figure out how to do that, fine. They win. If neither can, then get ready for IBM to do it. >>For systems such as SVG and >>X3D that have both rendering and behavioral fidelity >>issues, that won't work. >It works on a sliding scale. Vendors seem happy to support standards, >up to a point, then mysteriously lose interest. Ditto for more ordinary >developers, even without the big cash windfalls. Right again. Adolescents. Not good enough. >>XML doesn't do much to >>help with either of those. The DOM is >>helpful because it provided one of the vendors >>(bitManagement) a cheap way to get X3D into a >>VRML97 object model. But not merely because >>of DOM; it is a stringyfying means to manipulate >>the string representation. It worked because >>the VRML97 and the X3D object model have a temporal >>parent-child relationship; that is, they are >>genetically compatible, they are, versions of >>the SAME object model. Extensions to the >>string representation have to be matched in the >>object models to keep being compatible. >I don't think this has much to do with the larger question of symbol >grounding. That is precisely the question of symbol grounding for computer systems. I am not talking about the humans. We don't have to program them even if we do have to indemnify their behaviors (don't believe that? read your contracts with regards to the right of any customer site to refuse your employees' access.) >>That is just one language and it is not extended >>via XML namespaces because it has multiple encodings. >>That is a problem. On the other hand, it is extensible >>via the object model and that applies to any encoding. >Anything's extensible, if you're willing to bear the costs of extension. Can it be extended by anyone without prior consultation? That is the real meaning of independently extensible. XML punts that away by grounding itself only in the syntax. XML systems punt that away by encapulating it in a subdoc handler with an API. Ad hoc namespace combinations are meaningless to the computer. >>Again, we must separate XML language design from >>system design, then work out standard means for >>grounding the XML symbol sets (aka, application >>languages and even fragments (see Tim's UL example)) >>in the object models. Then we have to really face >>up to the fact that it is the object models that >>are interoperating, not the XML representations. >I won't touch object model interoperation. Tell me what the bytes on >the wire look like, and I'll create, buy, or borrow an object model. Fine. Will you indemnify it to me when I buy your product? To what extent will you indemnify it? By what contract language and by what references will you indemnify it? Can't do that? Fine. Next submittor, please. >Standardizing the object model interfaces is fine in some contexts, >especially where developers want to be able to script those interfaces, >but I think DOM demonstrates what an enormous mess that can evolve into >as the size of the model and the number of potential participants grows. Again, no d'oh. That is why international standards are reviewed every five years. That is why the Web3DC has a working relationship with ISO that enables the consortium to continuously adapt the model and then upgrade the standard. There is a reference issue there for contracting, but it is manageable. The response to your comment is, well, that's what managed code is all about. >>And we must do this in standards, because otherwise, >>both the reliability of the system and the risks >>of invoking IP trip wires are unmanageable for the >>customers. If the software industry, both open >>source or proprietary, refuses to indemnify its >>products, the customers must demand and buy products >>based on royalty free standards where all IP is >>declared, therefore the risks of downstream licensing >>are minimal, and the implementations are against >>known predictable designs. >I see no must. Next submittor, please. >>Much is at stake here. The customer is frikkin' tired >>of paying for the silliness and business cupidity >>of the software industry. I don't give a flying >>hoot what Torvalds or Balmer think they have going >>for them: they will provide product that meets the >>same terms as a bloody lightbulb and they will >>guarantee that or they will go out of business >>and be replaced by those that can. >I'd be thrilled to put a halt to market cupidity, but I don't think that >would solve the problem you're raising. It will be better. A lot of the software industry nonsense will cease when these guys finally have to grow up and face their customers with more than morality plays, causes, and airy demos. Whoever solves the indemnity problems wins the market. It is plain, it is clear, and it is coming. Vendors can do what Netscape did when XML was planned, and stick their heads in the sand and lose their markets. Fine. Next submittor, please. 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
|