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 ]

Thank you, Alaric.

Finally, someone thinks architecturally, that is, 
systematically, which is the point of the symbol 
grounding article:  one cannot ground symbols without 
a systematic means for compositing the primitives of 
the symbol set into meaningful statements where 
meaningful, in our case, is running code.  Note 
also that the article clearly delineates human 
behaviors, and even if we 'intend' machine behaviors, 
it is the coupling of symbols to behaviors that 
form the system.  

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

For those that responded "XML is only a syntax, 
why should we care" thread, peace.  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.  That is what an 
HTML, X3D, SVG, or XSLT document is for.  That is 
what XML application languages do.  The question 
is intended to elicit discussions of the utility 
of combinations of 'application languages'.  Why 
and how should we combine these and what combinations 
are meaningful?  MathML:  might fit anywhere. 
HTML:  fits on any surface.  SVG fits on any
surface.  X3D: fits in a device context.  It 
can contain HTML, MathML, SVG in theory, but 
practically, only SVG is a like system and 
there are object model problems with putting 
these together meaningfully except where, again, 
the SVG is composited into a surface (say Material 

There is a hint here:  the meaningfulness 
of the combinations can only be determined by 
the compatibility of the object models because 
as we all know, the meaningfulness of the 
syntactic combinations is essentially zero except 
by inference (yes, an interpreter can be created 
to analyze it like natural language but so what). 

Dare:  Internet Explorer.  See the means for 
annotating the presence of VML in an HTML document. 
Big surprise.  It uses a namespace declaration. 
Note also, how to attach htc behaviors using namespace 
declarations.   It provides a means to discover 
that the document asserts the namespace aggregate 
is 'meaningful' by declaring it in the root and 
associating it to the semantics via the CSS stylesheet.

Note:  Linda Grimaldi published a piece of RDF on 
this list last week that resolved to a piece of Java.

So clearly namespaces rightly or wrongly, morally or 
indefensibly, big endian or little endian, without 
regard to the philosophical or legal or sanctioned
efforts of the standards committees ARE BEING USED 

Alaric, you mention a global registry. A local registry 
suffices for working out when handlers implement 
object tags, a sort of SGML-like subdoc approach.  
A global registry is like a web service in a sense. 
Isn't possible even if highly inefficient to 
hook up semantic engines as services?

Folks, when Don Box mentioned Software ICs (an old 
term from the Cox books), did anyone think to associate 
Software ICs with registered names?

Forward progress on the web as a system, or even 
as an operating system, begins with an abstract 
object model for the so-called, standard web browser.
This must be a standard browser, and I do mean, 
an international standard, not a wiki or simply 
an open source code party.  Both of those are 
desirable but not the means by which the system 
is defined.

The DOM isn't good enough.  XSLT is just a 
transformation language.   CSS is pretty good. 
RDF... maybe.  One needs a way to describe an 
abstract object model of the browser that 
is mappable to the XML namespaces and by 
which, one can easily declare meaningful 

RSS won't be extensible in and of itself 
without something similar.  We really 
must differentiate XML language design 
from XML system design.


From: Alaric B Snell [mailto:alaric@alaric-snell.com]

Dare Obasanjo wrote:

> 1.) I can take a vanilla XSLT processor and pass it a stylesheet with
> EXSLT extension elements which my XSLT processor automatically learns
> how to process as valid stylesheet instructions. 
> 2.) I can take a vanilla W3C XML Schema processor and pass it a schema
> with embedded Schematron assertions which it automatically learns how to
> use to validate an input document in addition to using the W3C XML
> Schema rules. 
> since these are both "simple" cases of mixing XML vocabularies with
> agreed upon semantics. 
> As far as I'm concerned this is an unfeasible problem to attempt to
> solve and claiming otherwise is as ludicrous as the claims many were
> making about AI in the 80s and about the Semantic Web in the 90s. 

I wouldn't call those unfeasible... hard, maybe, but not impossible.

To solve it takes a few prerequisites:

1) Some way of getting code to run on anything. Perhaps fat binaries. 
Perhaps a really minimal bytecode - a stack machine of some description, 
maybe - that can be interpreted or compiled. Perhaps java. Whatever. 
With a sandboxing mechanism.

2) Standard interfaces for, for example, schema checking systems 
independent of the schema language, so one can write interchangeable 
modules for XML Schema and Schematron.

3) A global registry mapping namespace URIs to bits of code that 
'implement' them.

4) Better definition of the semantics of extension. In XSLT, I imagine 
that an XSLT processor might be implemented in terms of a recursive 
algorithm that, alternates between a pattern matching mode and a rule 
executing mode. In rule execution, it might have a big lookup table of 
"xsl:for-each" and friends to decide how to evaluate each part of a 
rule. In pattern matching, it might have a big lookup table of 
"xsl:template" and... nothing else. So one might generalise that lookup 
table into "look up the namespace URI in the global registry, check that 
the returned module does indeed implement the 'Transformation' 
interface, and then feed it the element name invoked along with the 
transformation context and input and details of what to do with the 
output etc. etc.".

5) Somebody to write those modules! Presumably this could fall to the 
namespace authors - the schema for elements in the namespace and the 
standard semantic declaration would go hand in hand.

Note that this isn't *forcing* semantics; it's just *providing default* 
semantics. You'd still be free to parse an XSLT stylesheet and use it 
to, say, produce a nice diagram of the transformation it embodies, using 
your own knowledge of XSLT. The semantic modules might well only define 
the semantics of those elements and attributes and extension functions 
and whatnot when used for transformations. And you would be free to hard 
code in your transformation engine that you know a quicker way to 
implement xsl:template using some special hardware or algorithm you have 
lying around, and thus avoid using the interpreted bytecode of the 
official semantics, but then it's your job to make sure your semantics 
matches theirs in all the areas that matter.

A renderer might have a generic layout model for rendering, perhaps the 
CSS box model, and it would dispatch based upon namespaces to semantics 
modules for each namespace and, as long as they support the rendering 
interface, ask them to render themselves. Thus XHTML, Docbook, MathML, 
and so on could all coexist happily; Docbook might implement rendering 
by just applying some XSLT to itself then chaining to the XHTML 
renderer. Stuff like RDF embedded in HTML might not implement the 
rendering interface, in which case it would have no effect on the 
display - it'd just be ignored. Other problems than rendering might take 
a harsher opinion of namespaces for which an implementation of a 
relevant interface cannot be found. But maybe XHTML and friends might 
declare, in their semantics in the global registry, that they can be 
used for 'documentation', in which case document types without explicit 
documentation elements might just allow elements from their namespaces 


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

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