OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Symbol Grounding and Running Code: Is XML Really E xtens

[ Lists Home | Date Index | Thread Index ]

From: Simon St.Laurent [mailto:simonstl@simonstl.com]

clbullar@ingr.com (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

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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS