[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 Extensib
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@a...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|