Lists Home |
Date Index |
firstname.lastname@example.org (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.
>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.
On the bright side, that might finally abolish namespaces.
>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.
>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.
>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 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.
>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.
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.
>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.
>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.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org