[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Stepping back, for a moment...

Subject: Stepping back, for a moment...
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Mon, 23 Nov 1998 15:17:45 -0600 (CST)
what is transformer feedback
   I've been lurking over the discussions regarding transformation and
formatting capabilities for XSL for some time now.  I've found this to
be of particular interest, as I have long wondered exactly what the
point of XSL was at all, given DSSSLs excellent architecture and
extensive abilities (if we were ever to get a more complete
implementation of it, including the transformation language - not to
say that Jade is useless, because it certainly isn't).  The only
explanation I could come up with was the desire for something more
declarative and accessible to non-programmers.
   In any case, after reading many messages, I have collected and
refined my thoughts to the point where I'm ready to take a shot at
expressing them.  Here goes.

   First of all, I would like suggest we begin to think in terms of a
layered approach.  This, in my experience, is the best possible way to
meet a broad range of needs in as flexible of a fashion as possible.
As an example, think of a basic programming situation.  You have a
range of tools to pick from in any programming project.  You can do
your project in machine code.  It takes much knowledge and talent, and
will take (probably considerably) more time than any other option, but
you have *total* control of the machine, and can pull off anything
that the hardware allows (and possibly more, if you're really talented
:).  The next step up would be a fine-grained high-level language,
such as C.  Here, you have a whole range of tools and abstractions
that keep you from having to deal with the myriad of details that
machine code would force you to consider.  You don't need quite as
much knowledge (or, at least, somewhat easier to master knowledge),
and could probably complete the project in considerably less time.
However, you sacrifice a certain amount of control.  The next step up
would be a higher level language, such as Java or Basic, where you're
a little more removed from the details of the underlying hardware.
The same considerations apply.  After that, you'd move on to a 4GL,
where you largely use visual tools to assemble predesigned objects.
Lastly, you'd just use an off-the-shelf application.  Here, you're
very limited in your options, but you can accomplish the task in
(relatively) very little time and with considerably less knowledge and
experience required.
   So, to bring this lengthy analogy to a point, I think our best
direction may be to provide standards for the low-level building
blocks of these systems, and move up from there.  For instance, any
type of manipulation, be it formatting or transformation, requires a
parsed, structural representation of the document, both input and
output.  DSSSL uses the concept of a "grove" (which, I might add, is
an excellent concept, and should not be lost).  Also, the DOM standard
could well play into this level.  Once an interface to this level
(notice I say an interface to, not an implementation of) has been
standardized, we can build the next level (or, even a couple of
different options for the next level, so us DSSSL sadists could have
an implementation of DSSSL on top of this standard, and the rest of
the world could have something more sane, right?:).
   The next level, I assert, would be a transformation language.
What about a formatting language?  I assert that a formatting language
does not belong at the same semantic level as a transformation
language.  Rather, I assert that a formatting language belongs on top
of a transformation language.  This basic concept has been put forth
here before.  Formatting is simply a transformation to a model which
describes the physical layout of a document.  While I do find the
concept of TeXML interesting, I don't think this is necessarily the
best way to go, as it sacrifices the multiple output format option, as
David asserted here.  More on this in a moment.
   Thus, I believe that the formatting language would be defined in
terms of the transformation language.  Again, there would be the
flexibility for multiple options at this level, each based on a
transformation language in the level below.  It would even be possible
for the same formatting language to be implemented on two different
transformation languages.  The formatting language would provide a
layer of abstraction for the transformations that are really
occurring.
   At the next level (or the same, depending upon how you look at it),
would be the abstract representation of the formatted document,
otherwise known as formatting objects.  Again (and this has been
suggested before, as well), there would be multiple options available.
Certainly, some standard sets of objects would be needed so that we
aren't all speaking different languages, but special tasks have
special needs.  The DSSSL standard defines a pretty good base set of
objects, and would serve as a good basis for a generic set.  This is
where I see a solution to the formatter-to-transformer feedback
problem.  By creating abstractions for common situations where
feedback would otherwise be needed, we could eliminate the need for a
potentially complicated and difficult to implement feedback mechanism.
For instance, we could create a formatting object which represents a
footnote which may be inlined or placed at the bottom of the page
depending on certain criteria, much of which could be controlled by
the creator of the formatting object via properties of the object.  In
practice, this object would encapsulate the TeX code that David spoke
of writing.  This object could become part of an extended set of
objects for more advanced typesetting needs, beyond what, for
instance, the average web designer today would need.  Indeed, the
ability to define new formatting objects which arbitrary semantics
will be extremely important as new forms of media become commonplace.
Can you imagine where we'd be if a standard set of objects had been
set in stone before hypermedia (aka, the web) had come into common
use?
   So, to wrap up this somewhat incoherent rambling, I think some
larger scale analysis of what we're really out to do may be in order
(and indeed, has begun in these past days), and that the answer may
require a fundamental shift in approach.  One grand solution may be
nice, but is not often feasible.  A modular approach opens up the
field for a range of solutions tailored to different needs, but does
provide some unity of framework.
   I do have a real world example I'd like to present which
demonstrates some of the ideas and motivations behind my thoughts
here.  It's fairly simple, but demonstrates some important things.  I
shall try to assemble a presentation of it as soon as I can.
Hopefully, it will help to make my ideas a bit more concrete.  As
always, I am open to any and all comments, ideas, and (constructive)
criticisms of my thoughts.

-Brandon :)


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.