[
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
>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
|
