You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Scott Boag/CAM/Lotus <Sc...@lotus.com> on 2000/05/01 01:11:19 UTC
Re: Another type of XSLT
Hi John. I enjoyed your note very much. Incremental transforms has always
been a design criteria of XSLT, which is why it doesn't do things like
reasignable variables. Yes, some of these transforms are hard, but it
should always be possible to find out how much of the result tree needs to
be updated.
I'm not sure why you need something called "XSLP". The XSLT result tree is
*not* an XML document, and can be either a true "view" or a mixture of new
elements and references to the source tree. This is a matter of good API
for the XSLT processor, and a browser that understands such things. To do
this with today's HTML browsers, you'll have to set up some sort of event
mechanism that can send modification events from the source tree to some
sort of adapter, that can then kick off an incremental transform, and then
update the HTML browser's view "DOM". Does this make sense?
> Based on my understanding, XSLT operates like a filter.
> A source document is filtered through a stylesheet resulting
> in an entirely new document.
>
> xmldoc1 -----stylesheet-----> xmldoc2
It's more than a filter. You are both adding nodes, filtering nodes, and
perhaps splitting nodes. All XSLT processors out there currently do a copy
process, but there's nothing in the XSLT spec that dictates this. In fact,
copying all the data is a pretty bad way to do things.
> How realistic and efficient would such a process be?
Realistic and efficient, but somewhat hard.
> Have there been attempts by others at this and if there are,
> how successful were they and how can I find them?
I did some early work on this type of thing, but I never published it. I
don't know of any public implementations of this kind of thing, which isn't
to say their aren't any. If you find something, please let me know!
> Can Xalan be adapted to include this functionality?
Yes, we have something along these lines in the plans, but not being
actively implemented right now.
> Or
> should I look elsewhere for other implementations that
> have more flexible designs?
I think Xalan 1.1.x will be a pretty good place to do this kind of thing.
But, then again, I'm biased. :-) I badly want to do this kind of thing
for Xalan.
What you really need to think of is, what will the XSLT Processor API look
like to support this?
> What other free implementations of XSLT are there? I
> think Mozilla has a program called transformix, but I
> haven't looked at it yet.
Take a look at http://xslt.com/xslt_tools.htm, and some of the other xml
tools pages lurking about.
-scott
"John Ky"
<newhoggy@yah To: <xa...@xml.apache.org>
oo.com> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Another type of XSLT
04/28/2000
10:46 AM
Please
respond to
xalan-dev
Hi list:
I plan to do some work on an XSLT variant but before I begin,
I thought it a good idea to consult some people who know XSLT
inside out.
Based on my understanding, XSLT operates like a filter.
A source document is filtered through a stylesheet resulting
in an entirely new document.
xmldoc1 -----stylesheet-----> xmldoc2
"xmldoc2" is produced from "xmldoc1" using "stylesheet".
Changes to "xmldoc1" are not reflected in "xmldoc2". In
order to get the most current styled document, a new
transformation must be made each time xmldoc1 is changed.
This is not a problem in many applications such as the
construction of web-pages from data.
For other applications this approach is sub-optimal, clumsy
or at worst disastrous.
Take for example the running of XSLT on a browser (ie.
client side). The browser retrieves an XML document
from the server. The browser then filters this through a
stylesheet to produce an XHTML page, which is displayed
to the user.
So far, traditional XSLT copes with the situation.
Now, the web-page is improved to also allow the modification
of the local XML document by the user. Changes to the XML
document must also result in display changes to the user. That
is, the XHTML document that the user sees must be modified
to reflect the changes in the XML document.
Well, that is fine, simply run the XML document through the
stylesheet again. The new XHTML document produced
should be exactly as required.
But it is not so simple. The new XHTML document is exactly
that: a NEW document. From the users perspective this is
equivalent to loading a new web-page and that is not always
what is desired.
Consider for instance that the visible document is very long, and
the user is editing from somewhere near the end of the page. A
small change is made to the underlying document (data model)
which triggers a stylesheet transformation. The new XHTML
document is displayed with all the correct changes, however,
as the new XHTML document is a modification of the old
XHTML but a newly created document the browser looses
track of its position in the document and scrolls all the way back
to the top. In addition, form-controls that had the users focus no
longer have focus - This is because, even though the new document
has the same form-controls, those aren't exactly the same: The old
one form-control with the focus is destroyed and a new one with
all the same properties is created but without user focus.
Furthermore, the repeated transformation is inefficient. All it
takes is a very minor change in the XML document to require
a tranformation. For large stylesheets and large XML documents
producing large XHTML documents. Retransformation is very
costly and the user may not appreciate the drain on CPU
resources.
_________
I wish to explore another type of process very similar to XSLT,
but which isn't a filter. It is more like a view. For the moment, I'll
call it XSLP which stands for XSL Projection. Here, there is
still a source XML document and a stylesheet, but no XML
document is actually produced. Instead an XML view of the
original document is maintained. The XML view is read-only and
will always reflect changes in the source document.
The stylesheet used is still a standard XSLT document so there
is no problem with standards conformance.
xmldoc =====stylesheet====> xmlview
Again, there is no 'transformation'. Instead there is a projection
of the XML document. The XML document could be changed
by the user and the view will automatically show that.
The XML document could be streamed in via a network connection
and xmlview will be consistent with the local document at every
stage of its construction.
My questions, are:
Question1:
How realistic and efficient would such a process be?
Re: Another type of XSLT
Posted by John Ky <ne...@yahoo.com>.
> I'm not sure why you need something called "XSLP".
Heh, at the time I thought to make things simpler for myself. :)
I'll outline my reasons for the name "XSLP" here:
1. I was being cautious - I was afraid that all of XSLT could not be
implemented
incrementally. Even if XSLT can be implemented incrementally at this stage,
it
does not guarantee that XSLT will eventually be extended with
non-incremental
functions. Your reassurance that XSLT was meant to be incremental in the
first
place dispelled those fears. I am still unsure, however. I read about
things like
<lxslt:script/> and get freaked out because it is beyond me how these things
could possibility be incrementally transformed. If <lxslt:script/> was
restricted
to only allowed declarative functional languages, like Haskell, I still
worry - but
at least not so much. (No language produced side-effects to worry about -
but
listeners would still need to be hooked on any source of information
external to
the source document)
Hence XSLP (or maybe iXSLT or pure-XSLT) would be names to use if
circumstances forced incremental and full transform standards to diverge.
I would be very happy if this didn't happen. A new language was never
my intention.
2. It didn't occur to me at the time that incremental transformations could
be faster than some of the methods used for transformations today. My
reasoning for this oversight had been my observations that incremental
transformations operate under a more restrictive environment. A full
transformation can be implemented by doing a series of incremental
transformations but not vice versa. So optimal full transformation will
always be at least as efficient as incremental transformations if not more.
(I'd welcome brighed minded researchers out there to proved that the
opposite is also true - then I wouldn't need to worry so much)
If incremental transformations do happen to be the most efficient way of
implementing full transformations (fingers crossed), then there isn't any
question to it: Both transformations can co-exist with a single
implementation - the full transformation API being exposed as a facade
to the incremental transformation API.
On the other hand, if that is not the case and faster full transformations
are possible, then there'd probably be no end to complaints about
Xalan's speed. That's where users' appettite for better/faster
transformations
will probably force a split.
3. Yeah and ofcourse that bit about the result tree being an XML document.
Had the result tree been an XML document then there would have been
a need to use a modified/extended DOM which implies another API, which
would need another name.
I suppose that this is no longer a problem.
4. All trivial things need a name. It's this human crave to classify,
identify
and communicate. What else are the words 'zero' and 'null' are for? How
about a nice short name for incremental transformations? I think iXSLT
would be better than XSLP. The 'i' appears everywhere these days and
the sheep in me wants to follow :)
John
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com