[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Symbol Grounding and Running Code: Is XML Really E xtensi

• To: "'Simon St.Laurent'" <simonstl@s...>, xml-dev@l...
• Subject: RE: Symbol Grounding and Running Code: Is XML Really E xtensible?
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 13 Aug 2003 10:10:18 -0500

There certainly are ways to think independently about 
the applications of XML.   There are also ways to think 
about common problems and that is what standards are 
there to express.  Not "how identifiers can help me" 
but how I can use identifiers and how I can communicate 
that use with a minimum amount of prior agreement.  I 
don't believe that it can be done without some prior 
agreement but the degree of that depends on what one 
wants to get done, with whom, and often, how many.

We don't have to pretend to globally agree.  Some 
set of people can, however, agree.  That is standardization.

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? 
 
I can't go down a path where 'everyone does their 
own thing with the markup'.  For systems such as SVG and 
X3D that have both rendering and behavioral fidelity 
issues, that won't work.  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.

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.

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.

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.

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.

len


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

clbullar@i... (Bullard, Claude L (Len)) writes:
>Finally, someone thinks architecturally, that is, systematically,
>which is the point of the symbol grounding article

There are lots of ways to think architecturally without having to fall
for the "systematic" virus.  (Heck, I think a lot of architects would be
the first to find fault with the systematic nature of building in the US
today.)

Reading the Harnad article, he hedges pretty severely on how systematic
an approach he's creating. "If both tests are passed.... This is still
no guarantee... if the system's behavioral capacities are lifesize..."
These are nice thoughts, but it's still worth questioning what the
"symbol system" actually contributes here and whether a formal system
per se is necessary.

>We all know XML is only a syntax, but coupling it to behaviors is what
>XML systems are about and what the notion of symbol grounding is
>about. 

You seem to be pushing for a much more general notion of symbol
grounding ("Why and how should we combine these and what combinations 
are meaningful?") that I don't find plausible or worthwhile.  Sticking
with the syntax lets us abandon grand and complex visions about sharing
semantics and get work done through more local mechanisms.  

"Coupling [XML] to behaviors" in a systematic way is an invitation to
pretensions of global meaning that seem primarily to waste a lot of time
on www-tag.

>No identity without identification.  No meaning without code.  That's
>the web because that's a computer.  Debate the details as long as
>necessary.

You might have enjoyed Bill Kent's keynote at Extreme last week.  It did
a nice job of exploring how identity is a problem, and how we can still
work despite the painfully real nature of that problem.  In large part,
it suggested (to me) that we should lower our expectations about what
identifiers can do for us.

• Follow-Ups:
  • RE: Symbol Grounding and Running Code: Is XML Really E xtensible?
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: XML database enviroment using PostgreSQL
• Next by Date: Re: Symbol Grounding and Running Code: Is XML Really Extensible?
• Previous by thread: Re: XML database enviroment using PostgreSQL
• Next by thread: RE: Symbol Grounding and Running Code: Is XML Really E xtensible?
• Index(es):
  • Date
  • Thread