xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clark C. Evans" <clark.ev...@manhattanproject.com>
Subject Re: A mathematical vision of XML leads to interesting conclusions
Date Sat, 18 Dec 1999 06:27:45 GMT


A bunch of us have splitered off from the main group to work on 
such a problem, "SML", "simple markup language". We have two goals.  

The first is to generate a minimal subset of XML that satisfies 
80% of the practical needs -- tossing out much of the unnecessary 
items from XML.  

The second goal is to build up a new "othogonal" collection
of (perhaps incompatible) extensions, coming from both 
pratical needs and theoretical experimentation.  For instance,
I feel that MURATA Makoto's work on hedge/forest automata
should be explored in far more detail.

Thus, the first goal gives us a workable recursive tagging
language to meet todays needs and the second goal will help
us scale to tomorow's problems; by fostering open competition 
for the best improvements in the language instead of relying 
upon committee declarations.


Anyway, one of the first things I hope to get out of the SML
effort , is a unified SAX/DOM "accessor".  I call it an accessor, 
beacuse the layer provides access to the SML(XML) source.  Parsing, 
of course, may be part of that process.  Many of us have created
various variants of this.   Sean Mc Grath's Pixie being a
one of several attempts.  We've also tinkered with such a thing,
on the Cocoon list, I believe calling it a lazy DOM.  For Cocoon, 
such a tool would serve as the "coupling" between processor 
stages; just as DOM is innefficent with regard to space, I think 
SAX is inneficient with regard to time.  A unified "accessor" 
would in one extreme be like DOM, in the other extreme would 
be like SAX -- only it  would, have the whole spectrum of
intermediate possiblities. 

Best Wishes,


P.S.  It's neet to see the PIA folks on the Cocoon list...

On Sat, 18 Dec 1999, Stefano Mazzocchi wrote:
> People,
> it's no secret that I think one of biggest design mistakes in XML was
> keeping it SGML compatible, but it's easy to say this now and I think I
> would have probably made the same mistake. 
> The XML spec is almost entirely dedicated to the DTD definition and,
> unfortunately, the DTD patterns are old and don't keep up well with the
> XML world. Mostly, the problem is lack of namespace orthogonality, but
> hopefully the XSchema effort will patch DTD problems. Anyway, I still
> think that XML, XML-namespaces and XSchema are not orthogonal specs and
> they should be merged into a wider XML spec... keeping syntax
> compatible, of course, but allowing a more solid namespace driven
> validation.
> If you think about it, the namespace idea is the real key to XML
> success: namespaces are "versors" of an "infinite-dimension" solution
> space. Topologically speaking, while SGML is an single infinite
> dimension, XML is an infinite set of infinite dimensions. Mathematically
> speaking, you can create a one to one relationship with all the points
> of XML to SGML (like it's done considering, for example,
> "xsl:stylesheet" like a one dimensional SGML element, rather than the
> "stylesheet" element of the "xsl" namespace). This may lead to imply
> that SGML and XML have the same "multidimentional" volume. Thus,
> namespaces don't alter the topological tissue of XML (which remains flat
> and one-dimentional), but simply adds "classes" of elements to allow
> elements to share the same name, but have different meanings.
> The importance of thinking about XML as a multidimensional language is
> incredible since you inherit all the geometric patterns we are well used
> to: projection, orthogonality, clipping, translation, rotation can all
> have meanings applied in the XML world. Meanings that, like any powerful
> design pattern, express much more in a word that in a thousand pages.
> So, continuing in the topological equivalence, XPointer define geometric
> points in the XML space and XLink define translation vectors, arcs or
> vector sets, from one point (the XPoint where the XLink is present) to
> one, more or a chain on points.
> But there are two important differences between XML and a mathematical
> vision:
>  - XSLT is not a rotation (unlike math transforms): this because
> information is created and lost during the transformation. This implies
> that there cannot be such thing as an anti-XSLT.
>  - XSLT mixes patterns from both transformations, generic functions and
> convolution, but not allowing to go further down with the mathematical
> equivalence.
> But one thing should be noted: there is a lot in common between the
> convolution pattern and the OOP inheritance pattern.
> While there is a proposed XInclude specification that aims to unify the
> need for inclusion of external things, there is very little concern
> about the application of more general object-oriented design patterns,
> such as inheritance.
> Donald and I both came to the conclusion that such inheritance facility
> would allow great simplification of the use of XML as data container,
> also allowing easier data-binding with OO languages.
> Let's make an example:
>  <page xml:extends="template.xml">
>   <title>Hello world!</title>
>   <body>
>    <p>This is to say hello!<p>
>    <p><strong>Hello!</strong></p>
>   </body>
>  </page>
> where "template.xml" is
>  <page>
>   <author>John Smith</author>
>   <body>Yet to be written!</body>
>   <legal>Copyright (c) Foo Inc.</legal>
>  </page>
> and after the parsing you get
>  <page>
>   <title>Hello world!</title>
>   <author>John Smith</author>
>   <body>
>    <p>This is to say hello!<p>
>    <p><strong>Hello!</strong></p>
>   </body>
>   <legal>Copyright (c) Foo Inc.</legal>
>  </page> 
> which is _very_ handy, expecially for XML web publishing.
> True, the above can be done thru XSLT transformations, but it's much
> more complex and Donald and I both think XSLT may fail to cover all the
> cases for useful inheritance.
> This is why we ask for your comments on such thing, hopefully to be
> included in the XInclude effort or in another W3C note, but think that
> inheritance should be a fundamental feature of the XML model.
> Awaiting for your comments and sorry for the non-math people around :)
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche

View raw message