Lists Home |
Date Index |
From: james anderson [mailto:email@example.com]
>despite the likelihood that, to begin with an ostensible
>counter-example to my view, the german courts will soon decide the
>meaning of the letter "T" in the context of advertising, definitiveness
>is not likely to prove the general case.
Yes. Much silliness because there can be. We have a TV network
suing a comic because the network trademarked the phrase,
"Fair and Balanced". IP reform is needed.
>as much as the world might be more tractable, were it possible to nail
>down the symbols denoted by the text strings in xml documents firmly
>and permanently, and to specify the meaning of a given symbol
>authoritatively, that is not likely to happen.
Not all, certainly. However, as Alaric notes, dispatching on
types is reasonable where types can be determined. A code
registration system is used in the local registry, and there
is no reason it can be globalized to a reasonable extent. It
may be the case that these turn out to be as they are now
for Microsoft, a private and well-protected location, but
it should also be the case that any implementor who cites
the standard for the code they register and distribute also
warranties a compliant and conforming implementation. It
puts the burden back onto the standards organization to
provide an object model with the standard. X3D has done this.
Others can. For data standards, the requirements are less
onerous, but that is another topic to explore.
>consider microsoft's .net patent application. just as machine age
>patents had to describe how a novel arrangement of specific physical
>components behaves so as to perform a particular function, a cyberage
>patent must, at least, describe how particular combinations of
>particular physical symbols is to be interpreted so as to perform a
>particular function. as dastardly as this particular patent may be, and
>even though this description form is not, in itself, sufficient to
>render the subject patentable, it is far better than most of the
>nonsense approved by the uspto and demonstrates somethng which would be
>lacking in a "rooted" scheme.
So we move the IP from the patent to the standard. That is in effect,
precisely what is happening. The next step would be to provide a
good enough model plus testing to clearly define what a warranty
for registered implementations provides. Clearly, this is a lot
of work, but I think it cheaper than lawsuits and better for
the customer than a EULA or GPL. More honorable too.
>the name for a namespace, per se, can never be sufficient to denote
>anything other than a predicate on a symbol. which denotes neither a
>specific set, nor a combination of its members, nor the interpretation
>of a combination of its members.
A namespace can name and can even locate implementations. Or it
can indirectly identify them via RDF, RDDL, etc. Or it can punt
to the local registry. Combinations such as are used in an
aggregate document type require a means to aggregate namespaces.
We do that in the documents now, sometimes by ganging them into
the root. My intuition is that over time, we discover that only
certain known combinations are showing up in the roots.
>when it comes to the means available to express concrete
>implementations, a programming language which relates the
>interpretation of a name to its context is more effective and
>expressive than one which has does not. the context may be a "package",
>a "function", an "object", or - in the ideal case - a combination of
>one or more of each of these. further more, the later this binding
>happens, the better.
Yes, but binding of known types seems to be wanted so that the
behaviors are predictable.
>to bind behavior universally and permanently to
>the name of schema is to return to a form of expression which "does
I disagree but no with universally and permanently. Those are obviously
overreaching conditions. Object models such as X3D provides work
wonderfully well. They do have to be maintained, but for languages
that have both rendering and behavioral fidelity requirements, they
are the best solution.
And they enable a market in which it doesn't always predictably come
down to a single vendor locking in the customers, as has been the
case for other XML rendering applications such as HTML and SVG.
Like it or not, not providing these models leaves the customers
and the programmers in a position to be co-opted.
>if i need to indemnify someone, i am prepared to do it based only on a
>standard which specifies the intended effect of particular combinations
>of particular symbols. for one thing, it requires less reformulation in
>the implementation in a adequately expressive programming language. for
>another i can expect the implementation to be more stable over time.
Yes. Today, we can only warranty our own work and we are passing
the EULA and the GPL to the customer. That is maddening for them
when they find out that SQLServer or Mozilla is upchucking and they have no
where to turn but the middle vendor, and the middle vendor has
no where to turn except to either maintain open source or
to beat up Microsoft. In the first case, it gets expensive;
in the second case, it doesn't help. Nothing gets rid of bugs
100%, but for some classes of what the IP lawyers call,
"essential facilities", the right to provide that to a
market should be paired to the obligation to warranty it.
Why not? Why should software be a privileged class
of product not subject to the same market requirements
as lightbulbs and the cars we drive?
>it does not matter to me how the standard is named.
But we have these namespace thingies. It seems to be
yet another "it's in the way that you use it" proposition,
and that is the essence of symbol grounding.