xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <bmcla...@algx.net>
Subject Re: A mathematical vision of XML leads to interesting conclusions
Date Sun, 19 Dec 1999 16:33:16 GMT

Stefano Mazzocchi wrote:
> Brett McLaughlin wrote:
> [...]
> > OK.  Do you have any "formal" spec written up?
> No, not at all: Donald needed it, he couldn't decide what to do so asked
> for my help... and I ended up writing that mail :)
> > There are several important items that come to mind:
> >
> > - I see how you allow elements to be overriden.  What about adding to?
> > For example:
> >
> > <page>
> >   <author>John Smith</author>
> >   <body>Yet to be written</body>
> >   <legal>Copyright (c) Foo Inc.</legal>
> > </page>
> >
> > I want to have my result look like:
> >
> > <page>
> >   <author>John Smith</author>
> >   <author>Brett McLaughlin</author>
> >   <legal>Copyright (c) Foo Inc.</legal>
> > </page>
> >
> > How could I do this?  If you are wondering , the importance of this is
> > an incremental bulding of a page.  What I am slowly wandering to is the
> > biggest problem we have today using XML in Java is that DOM is a hog,
> > and although SAX2 looks like it will allow us to move away from an
> > in-memory model, we still need XML techniques to incrementally add to an
> > XML document.  With a template system, this gets more complex, because
> > the additions may sometimes be additions, sometimes replacements.  So
> > the ability to take a template, possibly already parsed or in memory,
> > and not just replace elements/nodesets but add to them, and how to
> > represent the difference in XML, becomes important.
> You're talking about what I call the "now infamous" Simple Incremental
> Transformation Language (SITL). Clark and I have been arguing about that
> privately.
> In a couple of words:
> 1) should _not_ be as powerful as XSLT
> 2) should allow complete incremental operation
> 3) should be as simple to write as writing XML
> 4) should allow you to transform you XML "somewhat"
> (this "somewhat" is the key point to be defined that influences all the
> other points)
> and now we could add
> 5) should allow simple inheritance at the instance level
> [...]
> > But how do you do:
> >
> > [XML_1] + [XML_2] = ???
> >
> > This needs to be defined.
> I think we want to do something like
>  [XML_1] * [XML_2] =
> where '*' stands for "convolution".

Maybe I confused things here.  What I mean is that there should be some
algorithmic transformations/equations that are possible (these are the
less than XSLT items you talk about).

For example [XSL1] + [XSL2] != [XSL2] + [XSL1] in most cases because of
inheritance issues.  So how do I "add" or "extend" two XML documents.

[XSL1] * [XSL2] would be something different - and would only be
possible in certain situations.  Again, I draw analogies to Linear
Algebra, where to multiply two matrices, and the dimensions of the
matrices are a x b and c x d, b must be equal to c, and the resultant is
a x d.  This is getting closer to the namespace mappings you were
replying to about with Tim Bray.

I also think that the idea of a XML document as a line, and a XML
document with a namespace as a Vector is key.  That would make mapping
docments to each other another algorithm, not an XSL/T transformation. 
Consider the namespace A and the XML document [XML1].  I would like to
see namespaces handled as:

A * [XML1].  

The problem today is as you mentioned, the horrendous DTDs that can
results from multiple namespaces.  But consider, when thinking along the
lines above, that the mathematical equation for multiple namespaces in
one document would be:


where XML_FRAGMENT1 is the portion of the document employing namespace A
and XML_FRAGMENT2 is the namespace employing namespace B.  A complete
mapping from one namespace to another is also easily achieved:

(A * B) * ([XML1])

would give you all possible permutations... and then you could do
something like:

( (A * B) * [XML1] ) - (B * [XML_FRAGMENT2])

To give you a new resultant XML mapped to another namespace, yet without
having to have that new namespace in the final document!

The power of all this math is that mathematical formulae (of this
complexity) are almost trivial to code algorithmically, while of course
we all know XSL/T is not.

> > +1 Stefano, let me know if you need help.
> Of course I do... do you want me to write all that by myself? ;-)
> Anyway, let's start to brainstorm this with some examples of things we
> would like to be able to do and we'll carve a language out of that.

Exactly what I said above.  Define basic terms like "extends",
"concatenates", "expands".  Then begin to determine how mappings can
occur from one namespace to another.


> People, do you consider something like this "noise" for this list? If
> so, we'll move...
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>  Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------

View raw message