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 Extensib

[ Lists Home | Date Index | Thread Index ]

From: james anderson [mailto:janson2@attglobal.net]

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



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

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