[
Lists Home |
Date Index |
Thread Index
]
Mr. Snell proposes a solution to some tough problems that Mr. Obasanjo
thinks, if they are solved, would provide sufficient grounds for
successfully mixing arbitrary namespaces (that is, provide the requisite
semantics), and Mr. Bullard points out that namespaces are being used to
attach semantics to XML.
Having read most of this thread now, I'm convinced that terms like
"semantics" are being driven to different meanings than they can readily
support. Just as "artificial intelligence" is an oxymoron that raises
expectations beyond the possibility of fulfilling, so do "web ontology
language" and "semantic web". These philosophical terms, appropriated for
use outside their rightful context, are confusing what should be a
relatively simple issue, it seems to me.
Computers process symbols. Input is rearranged into output that is
convenient for us or for other machines to process further. Modern society
is replete with the value that this brings.
Reading Mr. Snell's outline of a solution looks to me like another layer (or
more) of machinery that can accommodate arbitrary namespaces provided there
is some super registry and other machinery to resolve ... . Well, the point
is, the symbol processing machine gets bigger and more complex. Attaching
various machine behaviors to various objects recognized by whatever means as
belonging to the appropriate class for that behavior, is nothing more than
what computers have always done, that is, process symbols. PhD in semantics
not required. If there really were meanings, which usually require
interpretation, the processing would not be mechanical, the results would
not be worth paying for, and we'd have long since trashed such machines as
unreliable junk.
The expansion of the web machinery to solve problems such as the one
occasioned by RSS appears to lead to a (possibly much) more complex machine
than was anticipated when namespaces were introduced. Do we need to "ground
the symbols"? As others have pointed out, no. Besides, that happens only
when a person looks at the symbols and understands them. Where the machine
is too large and complex for any one of us to understand, it takes a
community, or an institution to understand it. Machines, no matter how
complex, cannot do this, nor do they need to. That's our job, thank you.
I think the bigger question is, how do we pay for it? Building a web
machine that can perform this kind of processing requires standards ever
more cosmic in scope. Do we have the necessary experience and the vision to
see that large a picture? Can we and our current institutions support it or
not? Will the market embrace it, distort it, or ignore it? Is the benefit
worth the effort? Or can we afford to live on the edge of wilderness for a
while longer, taming it in smaller bytes?
--with my apologies if I've misrepresented anyone's comments.
Bruce B. Cox
SA4XMLT
USPTO/OCIO/AETS
703-306-2606
-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: Wednesday, August 13, 2003 10:17 AM
To: 'Alaric B Snell'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Symbol Grounding and Running Code: Is XML Really
Extensible?
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 node).
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 TO ATTACH
SEMANTICS TO XML TAGS.
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 combinations.
RSS won't be extensible in and of itself without something similar. We
really must differentiate XML language design from XML system design.
len
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.
>
> AND
>
> 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 willy-nilly.
|
