Andrew--

I share your annoyance/concern.

I think the schizophrenia involved with the committee's terminology comes
from the days when XSL encompassed both -T and -FO in one standard. They
were later broken into two separate standard proposals.

Now that they're separate, the simple fact is that XSLT is getting most of
the attention and press, and -FO tends to be forgotten in the "real world".

But, yes, I can't help but second your proposal for more accuracy in the
standards documents themselves.

Cheers!
Chris Ryland * Em Software, Inc. * www.emsoftware.com
----- Original Message -----
From: <AndrewWatt2001@...>
To: <XSL-FO@egroups.com>
Cc: <xsl-editors@...>
Sent: Tuesday, January 16, 2001 12:43 PM
Subject: [XSL-FO] A need for consistency and precision when referring to
"XSL"


> Robert & others,
>
> The issue addressed in this post may go some way to help some list members
> understand  why they are having problems understanding parts of the "XSL"
> Candidate Recommendation, which in my view would be better termed as the
> "XSL-FO" CR.
>
> What follows is a slight re-edit of a past post on another list.
>
> ***Re-edited quote begins***
>
> This post is a plea for a beginning in consistent use of the term "XSL" in
> W3C documents. The current CR stage of XSL-FO and the first WD of XSLT 1.1
> give an opportunity to W3C to remove longstanding inconsistent usage and
to
> introduce coherence and consistency.
>
> For those who have not yet considered the problem let me summarise the
> difficulty and inconsistency by the use of two "equations" which summarise
> two mutually contradictory positions about what "XSL" is which are taken
> (implicitly or explicitly) in the current versions of W3C documents.
>
> To avoid ambiguity I use the term "XSLT" to indicate XSL Transformations
and
> the term "XSL-FO" to indicate XSL Formatting Objects.
>
> The two equations are:
>  1.    XSL = XSLT + XSL-FO (see e.g. Abstract of XSL-FO CR)
>  2.   XSL = XSL-FO
>
> Stated as baldly as this I expect to potentially elicit howls of protest
> along the lines
> of "Of course XSL is the summation of XSLT and XSL-FO". But the statements
> currently present in various W3C documents contradict this assumed clarity
> and consistency.
>
> Let me illustrate. .... In the XSLT 1.0 Recommendation of November 1999 it
is
> stated in the Abstract, "XSLT is also designed to be used independently of
> XSL.", a statement which cannot be true if XSL = XSL-FO + XSLT (XSLT
cannot
> be used independently of "XSL" since XSLT is _part of_ "XSL") and
> contradicts, for example, the Abstract of the XSL-FO CR. However the
> statement also
> contradicts the position taken earlier in the Abstract of XSLT 1.0: "In
> addition to XSLT, XSL includes ....". So, XSLT seems to be "included in"
XSL
> but
> is also can be used "independent of" it. Something doesn't add up. What is
> happening is that the first part of the preceding sentence refers
implicitly
> to equation 1. and the latter part to equation 2.
>
> Thus, in theXSLT 1.0 Recommendation (and repeated verbatim in the XSLT 1.1
> WD) we have the use of both "equations". Which equation is true? Does XSL
=
> XSL-FO + XSLT or is XSL = XSL-FO? XSLT 1.0 effectively uses these two
mutually
> contradictory positions within a few lines of each other.
>
> The same inconsistency also appears in the current XSL-FO CR. As mentioned
> above the Abstract indicates unequivocally that XSL includes both XSLT and
> XSL-FO. But in Section 2, confusingly labelled "Introduction to XSL
> Transformations" it is stated, "The XSL namespace has the URI
> http://www.w3.org/1999/XSL/Format.". The placement of a statement about
what
> I would call the XSL-FO namespace in a section on XSLT is confusing
enough.
> But if, as the Abstract of the CR implicitly states, XSL = XSL-FO + XSLT
then
> there are two "XSL" namespaces viz. http:www.w3.org/1999/XSL/Format AND
> http://www.w3.org/XSL/Transform, not one as the XSL-FO CR states.
>
> There are many ways of slicing up these inconsistencies but, in my view,
they
> are founded in the use of "XSL" in the same documents to have two distinct
> meanings. Is "XSL" the same as "XSL-FO + XSLT"? Or is "XSL" the same as
> "XSL-FO"?
>
> I would suggest that the W3C "XSL" editors ... by which I mean the editors
> for the XSL-FO CR and the new XSLT 1.1 WD need to decide what "XSL" is and
> then use the term precisely and consistently. At present neither precision
> nor consistency is achieved.
>
> I hope these two examples serve to illustrate the ambiguity or
inconsistency
> of the use of the term "XSL" in current W3C documents. I could, quite
> possibly, go on at length about how the inconsistency plays out in various
> W3C documents. Rather, I think it is more important to find a solution
that
> is logical, clear and consistent.
>
> Suffice to say that the inconsistency within XSL/XSL-FO/XSLT specs plays
out
> to some degree in other specs too.
>
> My suggestion for how to move toward coherence would be:
>
> 1. Confine the generic term "XSL" to situations which refer to XSLFO _and_
> XSLT collectively.
> 2. When referring to XSL Formatting Objects the abbreviation to be used
> should be either "XSL-FO" or "XSLFO".
> 3. When referring to XSL Transformations the abbreviation used should be
> "XSL-T" or "XSLT".
> 4. It should be recognised that there are two "XSL Namespaces". The XSLT
> Namespace has a namespace URI of http://www.w3.org/1999/XSL/Transform. The
> XSL-FO Namespace has a namespace URI of http://www.w3.org/1999/XSL/Format.
> 5. The confusing "indicative prefix" (my term) for those two namespaces
> should be corrected/made consistent. I would suggest that the XSLT
namespace
> use the "indicative prefix" of "xslt" rather than "xsl" i.e. as an
example,
> the present
> <xsl:stylesheet> element would become <xslt:stylesheet>. Similarly the
"fo"
> indicative prefix would become "xslfo" i.e. <fo:root> would become
> <xslfo:root>.
>
> I would propose that the W3C Core XML Group (do I have the terminology
> correct?) review the current inconsistency in terminology across W3C specs
> currently in draft or under revision and give clear, unambiguous guidance
on
> which meaning "XSL" has in W3C documents.
>
> <side_issue>
> [ With regard to the more specific problem relating to the naming of the
> current XSL-FO CR could that not be called the "Extensible Stylesheet
> Language Formatting Objects, XSL-FO" Recommendation in due time? And could
> another very short "XSL" REC indicate that XSL version 1.0 subsumes the
XSLT
> REC of November 1999 and the XSL-FO REC, currently at CR stage? Then when
> XSLT 1.1 is finalised "XSL 1.1" could be defined as "XSL-FO 1.0" plus
"XSLT
> 1.1"? Just a thought. :) ]
> </side_issue>
>
> Consistent usage of the term "XSL" is desirable. With the current fluidity
of
> a XSL-FO CR and an XSLT 1.1 WD there is an early opportunity for W3C to
> introduce consistency where hitherto inconsistent and confusing usage of
the
> term "XSL" has been rather too visible.
>
> *** Re-edited quote ends ***
>
> Returning to Robert's question about the "fo" namespace and the confusion
> that that term caused him - If my suggestions were adopted we would refer
to
> that as the XSL-FO namespace with, in my view, much less ambiguity than a
> supposed but essentially spurious "XSL namespace".
>
> Sorry, to those for which this is pretty hard going. You need to be fairly
> familiar with how the specs use the terms to see that there is a problem.
And
> perhaps more familiar to diagnose it and suggest a (hopefully coherent)
> remedy.
>
> I hope that the XSL-editors wil prove responsive to these suggestions. It
> would make teaching some parts of XSL/XSL-FO/XSLT to relative beginners
just
> a little bit easier if the "standard" terms were used consistently in the
> definitive documents.
>
> Andrew Watt
>
> To unsubscribe from this group, send an email to:
> XSL-FO-unsubscribe@egroups.com
>
>

"Chris Ryland" <cpr@...> writes:

> [Ken MacLeod writes:]

> > I have created a "DOM lite" pattern that generally makes using DOM
> > and DOM-like trees a lot simpler in dynamic languages like Perl
> > and Python.  Flow objects (going back to DSSSL-FO) have always
> > been a target for this pattern, but I haven't reached the point
> > where my need has led to implementation and maintenance of the FO
> > nodes.

> Can you give those of us who just joined some background here?

A related question, probably much more basic, is: how many people are
interested in DOM-level access to FO trees, however simple or not?

It may be that some people are more interested in applying XSL-FO (via
XSLT, browsers, and formatters) than in dealing with FOs directly.

   -- Ken

Robert & others,

The issue addressed in this post may go some way to help some list members
understand  why they are having problems understanding parts of the "XSL"
Candidate Recommendation, which in my view would be better termed as the
"XSL-FO" CR.

What follows is a slight re-edit of a past post on another list.

***Re-edited quote begins***

This post is a plea for a beginning in consistent use of the term "XSL" in
W3C documents. The current CR stage of XSL-FO and the first WD of XSLT 1.1
give an opportunity to W3C to remove longstanding inconsistent usage and to
introduce coherence and consistency.

For those who have not yet considered the problem let me summarise the
difficulty and inconsistency by the use of two "equations" which summarise
two mutually contradictory positions about what "XSL" is which are taken
(implicitly or explicitly) in the current versions of W3C documents.

To avoid ambiguity I use the term "XSLT" to indicate XSL Transformations and
the term "XSL-FO" to indicate XSL Formatting Objects.

The two equations are:
  1.    XSL = XSLT + XSL-FO (see e.g. Abstract of XSL-FO CR)
  2.   XSL = XSL-FO

Stated as baldly as this I expect to potentially elicit howls of protest
along the lines
of "Of course XSL is the summation of XSLT and XSL-FO". But the statements
currently present in various W3C documents contradict this assumed clarity
and consistency.

Let me illustrate. .... In the XSLT 1.0 Recommendation of November 1999 it is
stated in the Abstract, "XSLT is also designed to be used independently of
XSL.", a statement which cannot be true if XSL = XSL-FO + XSLT (XSLT cannot
be used independently of "XSL" since XSLT is _part of_ "XSL") and
contradicts, for example, the Abstract of the XSL-FO CR. However the
statement also
contradicts the position taken earlier in the Abstract of XSLT 1.0: "In
addition to XSLT, XSL includes ....". So, XSLT seems to be "included in" XSL
but
is also can be used "independent of" it. Something doesn't add up. What is
happening is that the first part of the preceding sentence refers implicitly
to equation 1. and the latter part to equation 2.

Thus, in theXSLT 1.0 Recommendation (and repeated verbatim in the XSLT 1.1
WD) we have the use of both "equations". Which equation is true? Does XSL =
XSL-FO + XSLT or is XSL = XSL-FO? XSLT 1.0 effectively uses these two mutually
contradictory positions within a few lines of each other.

The same inconsistency also appears in the current XSL-FO CR. As mentioned
above the Abstract indicates unequivocally that XSL includes both XSLT and
XSL-FO. But in Section 2, confusingly labelled "Introduction to XSL
Transformations" it is stated, "The XSL namespace has the URI
http://www.w3.org/1999/XSL/Format.". The placement of a statement about what
I would call the XSL-FO namespace in a section on XSLT is confusing enough.
But if, as the Abstract of the CR implicitly states, XSL = XSL-FO + XSLT then
there are two "XSL" namespaces viz. http:www.w3.org/1999/XSL/Format AND
http://www.w3.org/XSL/Transform, not one as the XSL-FO CR states.

There are many ways of slicing up these inconsistencies but, in my view, they
are founded in the use of "XSL" in the same documents to have two distinct
meanings. Is "XSL" the same as "XSL-FO + XSLT"? Or is "XSL" the same as
"XSL-FO"?

I would suggest that the W3C "XSL" editors ... by which I mean the editors
for the XSL-FO CR and the new XSLT 1.1 WD need to decide what "XSL" is and
then use the term precisely and consistently. At present neither precision
nor consistency is achieved.

I hope these two examples serve to illustrate the ambiguity or inconsistency
of the use of the term "XSL" in current W3C documents. I could, quite
possibly, go on at length about how the inconsistency plays out in various
W3C documents. Rather, I think it is more important to find a solution that
is logical, clear and consistent.

Suffice to say that the inconsistency within XSL/XSL-FO/XSLT specs plays out
to some degree in other specs too.

My suggestion for how to move toward coherence would be:

1. Confine the generic term "XSL" to situations which refer to XSLFO _and_
XSLT collectively.
2. When referring to XSL Formatting Objects the abbreviation to be used
should be either "XSL-FO" or "XSLFO".
3. When referring to XSL Transformations the abbreviation used should be
"XSL-T" or "XSLT".
4. It should be recognised that there are two "XSL Namespaces". The XSLT
Namespace has a namespace URI of http://www.w3.org/1999/XSL/Transform. The
XSL-FO Namespace has a namespace URI of http://www.w3.org/1999/XSL/Format.
5. The confusing "indicative prefix" (my term) for those two namespaces
should be corrected/made consistent. I would suggest that the XSLT namespace
use the "indicative prefix" of "xslt" rather than "xsl" i.e. as an example,
the present
<xsl:stylesheet> element would become <xslt:stylesheet>. Similarly the "fo"
indicative prefix would become "xslfo" i.e. <fo:root> would become
<xslfo:root>.

I would propose that the W3C Core XML Group (do I have the terminology
correct?) review the current inconsistency in terminology across W3C specs
currently in draft or under revision and give clear, unambiguous guidance on
which meaning "XSL" has in W3C documents.

<side_issue>
[ With regard to the more specific problem relating to the naming of the
current XSL-FO CR could that not be called the "Extensible Stylesheet
Language Formatting Objects, XSL-FO" Recommendation in due time? And could
another very short "XSL" REC indicate that XSL version 1.0 subsumes the XSLT
REC of November 1999 and the XSL-FO REC, currently at CR stage? Then when
XSLT 1.1 is finalised "XSL 1.1" could be defined as "XSL-FO 1.0" plus "XSLT
1.1"? Just a thought. :) ]
</side_issue>

Consistent usage of the term "XSL" is desirable. With the current fluidity of
a XSL-FO CR and an XSLT 1.1 WD there is an early opportunity for W3C to
introduce consistency where hitherto inconsistent and confusing usage of the
term "XSL" has been rather too visible.

*** Re-edited quote ends ***

Returning to Robert's question about the "fo" namespace and the confusion
that that term caused him - If my suggestions were adopted we would refer to
that as the XSL-FO namespace with, in my view, much less ambiguity than a
supposed but essentially spurious "XSL namespace".

Sorry, to those for which this is pretty hard going. You need to be fairly
familiar with how the specs use the terms to see that there is a problem. And
perhaps more familiar to diagnose it and suggest a (hopefully coherent)
remedy.

I hope that the XSL-editors wil prove responsive to these suggestions. It
would make teaching some parts of XSL/XSL-FO/XSLT to relative beginners just
a little bit easier if the "standard" terms were used consistently in the
definitive documents.

Andrew Watt

Hello Chris,

    Bingo....
      That is what I was looking for...a simple, boiled down, no
nonsence, explanation......I hope thats what we are are looking for!!

nice touch....adding the SVG namespace :-)

thanks for your comment
Robert A. DiBlasi


--- In XSL-FO@egroups.com, "Chris Ryland" <cpr@e...> wrote:

I think all it's trying to say is that, after tree transformation by
XLST, the resulting tree is mostly FO objects (with the possibility
of other namespace objects, such as SVG).

  Cheers!
Chris Ryland * Em Software, Inc. * www.emsoftware.com
>   ----- Original Message -----
>   From: r_diblasi@h...
>   To: XSL-FO@egroups.com
>   Sent: Tuesday, January 16, 2001 10:27 AM
>   Subject: [XSL-FO] Re: 1.1.2 Formatting ...please help
>
>
>   Hello Andrew,
>
>   Amen.....
>          I believe your "crack" at the concept that was trying to
be
>   explained in the XSL spec is much clearer.
>
>         I still think that the uses of "result tree" (XSLT term I
>   believe) and "element and attribute tree" can cause trouble if
used
>   loosely....
>
>   I'm still having trouble with a phrase that is used:
>            "Tree transformation constructs the result tree. In XSL,
>   this tree is called the element and attribute tree, with objects
>   primarily in the "formatting object" namespace."
>
>
>   "with objects primarily in the "formatting object" namespace."????
>
>   What is the spec trying to say????

In a message dated 16/01/01 19:14:49 GMT Standard Time, r_diblasi@...
writes:

> "with objects primarily in the "formatting object" namespace."????
>
>  What is the spec trying to say????

Robert,

Due to time constraints I will respond only to this question at present.

The XSL-FO spec uses three terms (as I read it) for the same thing - in each
case the namespace URI is http://www.w3.org/1999/XSL/Format.

The spec, as I recall, uses three terms each of which appears to me to refer
to that same namespace URI and therefore mean the same.

The three terms are:

  1. XSL Namespace
  2. "fo" namespace
  3. "formatting objects" namespace

I am doing all this from memory so forgive me if I slip up on a word or two.

The spec also goes on to refer to "the" XSL Namespace.

But there are, in fact, two "XSL" Namespaces. XSL consists of both XSLT and
XSL-FO. The CR needs to edited more tightly in my opinion to reflect that
reality.

There is (my terms)
1. An XSLT namespace for which the namespace URI is
http://www.w3.org/1999/XSL/Transform
and
2. An XSL-FO namespace for which the namespace URI is
http://www.w3.org/1999/XSL/Format.

Since both XSLT and XSL-FO **together** constitute "XSL" we have two distinct
"XSL" namespaces with the respective namespace URIs which I have just given.

In my view the XSL spec editors need to take that on board and introduce
greater precision and  consistency in the use of terms.

I posted on another list recently about a related issue. I will try to dig
that out and post it within the next hour or two.

Andrew Watt

"Chris Ryland" <cpr@...> writes:

> [Ken MacLeod writes:]

> > I have created a "DOM lite" pattern that generally makes using DOM
> > and DOM-like trees a lot simpler in dynamic languages like Perl
> > and Python.  Flow objects (going back to DSSSL-FO) have always
> > been a target for this pattern, but I haven't reached the point
> > where my need has led to implementation and maintenance of the FO
> > nodes.

> Can you give those of us who just joined some background here?

The project we're implementing this pattern in is called Orchard, it's
in the very early stage so it's not ready for the general public, but
early adopters and beta testers are welcome (send email for access).

The point we're at now is adding more "information sets".  Our test
sets have been XML and RSS.  I'll use RSS as examples here because it
shows off Orchard's support of namespaces very well.

The general pattern is that Orchard is organized to deal directly with
"information sets", just the data (nodes and properties), and placing
behavior and processing of the data in modules, some generic for all
infosets and some specific to particular infosets.

RDF Site Summary (RSS), for example, is made up mostly of Channel and
Item objects (Items are news items appearing regularly within a new
Channel).  The RSS core has title, description, and URL properties.
RSS modules extend the core, via namespaces, to add domain-specific
properties as needed.  Two popular modules are the Dublin Core
metadata (author, date, copyright) and Syndication (update-frequency).

The data model looks like this:

   Channel       Item
   -------       --------
   title         title
   description   description
   dc:subject    dc:subject
   dc:author     dc:author
   items

Here, 'title', 'description', and 'items' are in the default namespace
of the Channel or Item node (the RSS namespace) and 'dc:subject' and
'dc:author' are in the Dublin Core namespace.  'items' is an ordered
list of Item nodes.

In implementations, Orchard uses the native property access syntax and
container class interfaces as much as possible to make using nodes
simpler:

   Ideal:   channel.title      channel.dc:subject
   Python:  channel.title      channel[(dc, 'subject')]
   Perl:    $channel->{Title}  $channel->{[$dc, 'subject']}

All nodes come with intrinsic properties:

   all nodes
   ------------
   intrinsic:node-type
   intrinsic:namespace-uri
   intrinsic:parent

All information sets are built on top of the same core node
implementation (this will allow for generic processing).

On the other hand, Orchard node types do not share and are not tied to
the inheritance model of the implementation language.  In effect,
information sets are "flattened" and quite simpler compared to
equivalent OO inheritance implementations.  Orchard has more of a
"shares common properties with" model than an inheritance model (which
I suspect fits FO very well):

   fo:block
   ------------
   <accessibility properties>
   <aural properties>
   <font properties>
     :
     :
   break-after
   break-before
   color
     :
     :

Property inheritance would be a new feature for Orchard information
sets, but well within the intended architecture.


At this level, Orchard makes direct access to the nodes and their
properties much simpler.  The goal is that this makes developing
software on top of the nodes (formatting, display, interaction) easier
as well.

   -- Ken

Does this list have a "digest" subscription option?

Nick Ridout

----- Original Message -----

From: r_diblasi@...

To: XSL-FO@egroups.com

Sent: Tuesday, January 16, 2001 10:27 AM

Subject: [XSL-FO] Re: 1.1.2 Formatting ...please help

Hello Andrew,

Amen.....
       I believe your "crack" at the concept that was trying to be
explained in the XSL spec is much clearer.

      I still think that the uses of "result tree" (XSLT term I
believe) and "element and attribute tree" can cause trouble if  used
loosely....

I'm still having trouble with a phrase that is used:
         "Tree transformation constructs the result tree. In XSL,
this tree is called the element and attribute tree, with objects
primarily in the "formatting object" namespace."


"with objects primarily in the "formatting object" namespace."????

What is the spec trying to say????

Ken--

Can you give those of us who just joined some background here?

Cheers!
Chris Ryland * Em Software, Inc. * www.emsoftware.com
----- Original Message -----
From: "Ken MacLeod" <ken@...>
To: <xsl-fo@egroups.com>
Sent: Tuesday, January 16, 2001 8:05 AM
Subject: [XSL-FO] interest in FO "DOM lite"?


> I have created a "DOM lite" pattern that generally makes using DOM and
> DOM-like trees a lot simpler in dynamic languages like Perl and
> Python.  Flow objects (going back to DSSSL-FO) have always been a
> target for this pattern, but I haven't reached the point where my need
> has led to implementation and maintenance of the FO nodes.
>
> What would people's interest be in seeing "lite" flow object nodes?  A
> corollary design pattern is the seperation of behavior (reading,
> writing, formatting) from the model (nodes), so implementing the nodes
> themselves is easy, reading and writing are fairly easy as well, with
> processing added on as seperate layers.
>
> Refreshing my memory with the current CR I notice that the breadth and
> depth of FO's has increased a lot since I last remember, but the
> simplification (over the DOM API) still applies and may even be more
> apparent.
>
> If someone is interested in helping me with this I think we can show
> progress pretty quickly.  The basic prototype (no internal validation)
> should be possible in a few hours, as it's basically a matter of
> entering the list of node types.  Additional features can then be
> added in steps.
>
>   -- Ken
>
> To unsubscribe from this group, send an email to:
> XSL-FO-unsubscribe@egroups.com
>
>

Hello Andrew,

  Amen.....
        I believe your "crack" at the concept that was trying to be
explained in the XSL spec is much clearer.

       I still think that the uses of "result tree" (XSLT term I
believe) and "element and attribute tree" can cause trouble if  used
loosely....

I'm still having trouble with a phrase that is used:
          "Tree transformation constructs the result tree. In XSL,
this tree is called the element and attribute tree, with objects
primarily in the "formatting object" namespace."


"with objects primarily in the "formatting object" namespace."????

What is the spec trying to say????


As far as I under stand XSL I read so far is:
(This may not be correct please feel free to pick at :-)

(tree transformation) the source document is checked by the XSLT
                       namespace for "patterns".  If a "pattern" is
                       found in the source content it is said
                       to "match" the XSLT namespace. The XSLT
                       namespace checks to see what should happen if
                       a "match" has occurred...by looking at its
                       Template. The template is a tree fragment. So,
                       as pattern are found in the source document
                       that match the XSLT namespace, tree fragments
                       are produced. the production is called the
                       "result tree".

                      As the "result tree" is being produced is now
                      Processed by XSL namespace. The "result tree" is
                      now called the "element and attribute tree".
                      When a pattern is the "element and attribute
                      tree matches the XSL namespace a Formatting
                      Object (fo)is inserted into the "element and
                      attribute tree". the tree that is produced by
                      this process is called the "formatted Object
                      tree"

  .........I'll  stop here before I make much of a fool of myself :-)

well.....any comments would be great....
correction to the above welcomed.....

sorry for the long post....
Robert A. DiBlasi

--- In XSL-FO@egroups.com, AndrewWatt2001@a... wrote:
> In a message dated 16/01/01 03:01:30 GMT Standard Time,
r_diblasi@h...
> writes:
>
> Hi Robert,
>
> My $0.02 follows below.
>
> > Hello,
> >
> >     What the hell.........I have been reading this sentence over
and
> >  over
> >  and I understand each part but I do not understand the whole.....
> >
> >  Formatting 1.1.2
> >      "Formatting interprets the result tree in its formatting
object
> >  tree form to produce the presentation intended by the designer
of the
> >  stylesheet from which the XML element and attribute tree in
the "fo"
> >  namespace was constructed."
>
> I think the short answer is that it is a badly drafted sentence.
There are,
> IMHO, more than a few them in the current XSL-FO CR. If you examine
the
> XSL-FO CR you will see that there is no identified "editor", unlike
the
> position with a typical W3C spec in development. The absence of
mention of an
> identified editor seems to be reflected in the absence, at this
stage, of
> consistently tight editing of the text.
>
> >  I think the last part is driving me crazy.....
> >
> >  "the stylesheet from which the XML element and attribute tree in
> >  the "fo" namespace was constructed."
>
> I think you have probably broken the sentence at the wrong place.
Having said
> that try reading the whole sentence replacing "stylesheet from
which" with
> "stylesheet using which". That is closer to what I think the
editors mean.
>
> >  Someone with a good heart help me.....
> >
> >  I believe it to mean
> >      Formatting interprets the result tree in its formatting
object
> >  form......(with Formating objects in the the result tree) .....
> >  to product the presentation intended by the designer of the
> >  spreedsheet.......it all goes to hell after this point :-)....
>
> BTW when writing out the sentence you replace "produce"
with "product" which
> makes it worse. :)
>
> LOL ... I have just scrubbed the reply I was about to make. I
thought I had
> cracked it, but then it slipped through my fingers. :) Proves your
point I
> guess. It's a horrible sentence. :)
>
> My attempt at a better version:
>
> "Formatting is the final step of a multi-step process. The first
step is the
> production of an XML element and attribute tree (also known as
a "result
> tree"), using an XSL style sheet and XML source document. The
result tree is
> "objectified" into a tree in the XSL-FO Namespace. Formatting is
the process
> of interpreting the result tree (the XML element and attribute
tree), in its
> formatting object form, into a display [or visual presentation].".
>
> Just my $0.02.
>
> I would also say that for the XSL editors to attempt to equate the
> "intention" of the designer with the actual process of
> formatting/presentation is unwise. That only applies if the
designer
> correctly writes a stylesheet to actually produce the result.
>
> In addition there is a further background suspicion I have (but
haven't yet
> had time to look at properly) - that the term "formatting" is being
used in
> more than one sense in the XSL-FO CR.
>
> >  Help....
> >  Robert A. DiBlasi
>
> I hope that's clearer. BTW if you look at the diagram a little
later in
> Section 1.1.2 that might help you visualise it.
>
> I have copied this reply to the XSL-editors at W3C. Hopefully they
will take
> the problems with this sentence into account when further
drafting/editing
> takes place. And if we have both failed to understand the meaning
that is
> intended they may, hopefully, provide a response which can be
posted on list.
>
> Andrew Watt

AndrewWatt2001@... writes:

> I can see that, in principle, it is "just" a multi-namespace XML
> document.  But feel there is potential there, in terms of usage,
> that I am not seeing yet. It feels as if something exciting is there
> but is just out of reach at the moment. I hope that makes some sense
> and doesn't sound like, totally, like the ramblings of a blithering
> idiot.

I'm reducing the reply to this to just one list because Orchard is
still in its infancy, so I'd rather take it one piece at a time for
development and then present, rather than theorize about future
support :-).

Orchard uses a very flexible, or "loose", data model that has
excellent support for namespaced nodes and properties.  One of the
reasons was explicitly for the support of multi-namespace nodes of
data.

In that context, you should be able to intermix FO (or SVG) nodes with
XForm nodes, as long as the semantics (probably from XForm) are clear.

   -- Ken

For those list members who are not already familiar with them please
take time to browse round Robin Cover's XSL pages on
xml.coverpages.org

Other links for the XSL-FO group can be accessed at

http://www.egroups.com/links/XSL-FO/

If you know of other useful links, particularly tutorial level
material for beginners I would encourage you to post those to the
links page.

Andrew Watt

I have created a "DOM lite" pattern that generally makes using DOM and
DOM-like trees a lot simpler in dynamic languages like Perl and
Python.  Flow objects (going back to DSSSL-FO) have always been a
target for this pattern, but I haven't reached the point where my need
has led to implementation and maintenance of the FO nodes.

What would people's interest be in seeing "lite" flow object nodes?  A
corollary design pattern is the seperation of behavior (reading,
writing, formatting) from the model (nodes), so implementing the nodes
themselves is easy, reading and writing are fairly easy as well, with
processing added on as seperate layers.

Refreshing my memory with the current CR I notice that the breadth and
depth of FO's has increased a lot since I last remember, but the
simplification (over the DOM API) still applies and may even be more
apparent.

If someone is interested in helping me with this I think we can show
progress pretty quickly.  The basic prototype (no internal validation)
should be possible in a few hours, as it's basically a matter of
entering the list of node types.  Additional features can then be
added in steps.

   -- Ken

As some recipients will know I am interested both in how SVG will work with
XSL-FO and how SVG will work with XForms.

What is causing me severe brain ache today is trying to get my mind round how
XForms and XSL-FO might work together.

Have any recipients of this email given any thought to that? Got any
prototype working code?

Perhaps I am suffering from incipient "Old Timer's Disease" ... :) ... but I
am having trouble seeing how it will all work. And what it will DO or be used
for. So if anyone is further on in that thinking I would appreciate insights
which will lead me to the "Ah NOW I see" stage.

I can see that, in principle, it is "just" a multi-namespace XML document.
But feel there is potential there, in terms of usage, that I am not seeing
yet. It feels as if something exciting is there but is just out of reach at
the moment. I hope that makes some sense and doesn't sound like, totally,
like the ramblings of a blithering idiot.

Responses on or off list would be welcome.

Andrew Watt

This post is largely by way of possibly bringing separate groups of
developers together.

SVG developers may, in the main, not yet be up to speed on the potential
implications of the XForms proposal at W3C. SVG developers who are interested
in this will find information at
http://www.w3.org/MarkUp/Forms/

The current XForms Working Draft, explicitly recognises that XForms will be
embedded within SVG documents (among other XML document types). XForms could
provide powerful and useful interactivity in SVG-based documents or web sites.

XForms developers may be interested to know that there is a working prototype
SVG-only web site accessible at
http://www.svgspider.com/default.svg

There are specific technical issues about accessing SVG-only web sites at
present. Instructions are given at the end of the email.

XForms developers / software companies who are looking for a test bed to test
XForms prototypes in a working SVG web site such as www.svgspider.com may
contact me at the email address from which this email was sent.

I hope that those interested in creatively combining these cutting edge
technologies can interact and move forward to realise the synergy which,
together, XForms and SVG can provide.

Andrew Watt
Instructions:
To access www.SVGSpider.com/default.svg
you will need the Adobe SVG Viewer version 1. The site is designed at present
to work primarily with that version.

It may be downloaded at www.adobe.com/svg/

At present version 2 of the Adobe Viewer is in beta. Once Version 2 is
released I will update the SVGSpider.com web site to accomodate the
differences in handling of XLinks between SVG Viewer versions 1 and 2.

Internet Explorer 5.5 works well with the site. A few problems arise with
Netscape. If using Netscape 6 the Adobe Viewer does not automatically plugin.

It is NOT possible to access the site using the URL www.svgspider.com

The XLink implementation in SVG Viewer Version 1 causes an error in IE5.5

In a message dated 16/01/01 03:01:30 GMT Standard Time, r_diblasi@...
writes:

Hi Robert,

My $0.02 follows below.

> Hello,
>
>     What the hell.........I have been reading this sentence over and
>  over
>  and I understand each part but I do not understand the whole.....
>
>  Formatting 1.1.2
>      "Formatting interprets the result tree in its formatting object
>  tree form to produce the presentation intended by the designer of the
>  stylesheet from which the XML element and attribute tree in the "fo"
>  namespace was constructed."

I think the short answer is that it is a badly drafted sentence. There are,
IMHO, more than a few them in the current XSL-FO CR. If you examine the
XSL-FO CR you will see that there is no identified "editor", unlike the
position with a typical W3C spec in development. The absence of mention of an
identified editor seems to be reflected in the absence, at this stage, of
consistently tight editing of the text.

>  I think the last part is driving me crazy.....
>
>  "the stylesheet from which the XML element and attribute tree in
>  the "fo" namespace was constructed."

I think you have probably broken the sentence at the wrong place. Having said
that try reading the whole sentence replacing "stylesheet from which" with
"stylesheet using which". That is closer to what I think the editors mean.

>  Someone with a good heart help me.....
>
>  I believe it to mean
>      Formatting interprets the result tree in its formatting object
>  form......(with Formating objects in the the result tree) .....
>  to product the presentation intended by the designer of the
>  spreedsheet.......it all goes to hell after this point :-)....

BTW when writing out the sentence you replace "produce" with "product" which
makes it worse. :)

LOL ... I have just scrubbed the reply I was about to make. I thought I had
cracked it, but then it slipped through my fingers. :) Proves your point I
guess. It's a horrible sentence. :)

My attempt at a better version:

"Formatting is the final step of a multi-step process. The first step is the
production of an XML element and attribute tree (also known as a "result
tree"), using an XSL style sheet and XML source document. The result tree is
"objectified" into a tree in the XSL-FO Namespace. Formatting is the process
of interpreting the result tree (the XML element and attribute tree), in its
formatting object form, into a display [or visual presentation].".

Just my $0.02.

I would also say that for the XSL editors to attempt to equate the
"intention" of the designer with the actual process of
formatting/presentation is unwise. That only applies if the designer
correctly writes a stylesheet to actually produce the result.

In addition there is a further background suspicion I have (but haven't yet
had time to look at properly) - that the term "formatting" is being used in
more than one sense in the XSL-FO CR.

>  Help....
>  Robert A. DiBlasi

I hope that's clearer. BTW if you look at the diagram a little later in
Section 1.1.2 that might help you visualise it.

I have copied this reply to the XSL-editors at W3C. Hopefully they will take
the problems with this sentence into account when further drafting/editing
takes place. And if we have both failed to understand the meaning that is
intended they may, hopefully, provide a response which can be posted on list.

Andrew Watt

Hello,

    What the hell.........I have been reading this sentence over and
over
and I understand each part but I do not understand the whole.....

Formatting 1.1.2
     "Formatting interprets the result tree in its formatting object
tree form to produce the presentation intended by the designer of the
stylesheet from which the XML element and attribute tree in the "fo"
namespace was constructed."

I think the last part is driving me crazy.....

"the stylesheet from which the XML element and attribute tree in
the "fo" namespace was constructed."

Someone with a good heart help me.....

I believe it to mean
     Formatting interprets the result tree in its formatting object
form......(with Formating objects in the the result tree) .....
to product the presentation intended by the designer of the
spreedsheet.......it all goes to hell after this point :-)....

Help....
Robert A. DiBlasi

In a message dated 15/01/01 18:14:28 GMT Standard Time, hgazdik@...
writes:

> I am trying to use the xmlns:fo="http://www.w3.org/1999/XSL/Format"
>  in my stylesheet to transform to HTML pages.
>  Is this possible at this point?? I am using the latest msxml3.dll.
>  I am also going to try and use this for ordered lists and items..
>  As of right now I am using a template for the emphasis tags:
>  <xsl:template match="EMPHASIS">
>
>       <xsl:apply-templates/>
>
>  </xsl:template>
>  But would like to use:
>  <xsl:template match="EMPHASIS">
>   <fo:inline-sequence font-weight="bold">
>          <xsl:apply-templates/>
>   </fo:inline-sequence>
>  </xsl:template>
>
>
>  I appreciate any help,
>  Heather Gazdik

Heather,

I am not entirely sure what you are asking. I think what you are saying is
that you have an XML source document, you want to transform it to HTML and to
display it with emphasis on particular qualifying terms and had been trying
to use/incorporate XSL-FO.

Could you please use plain text when posting? I think your mail editor is set
to send HTML and that gets terribly mangled by the time it gets to this end.

OK ... to try and answer your question.

To the best of my knowledge there is no browser which can display XSL-FO
mixed with HTML/XHTML.  I may be wrong here because I know lots of people are
working on new tools. As of now I don't know of any such browser/viewer.

Assuming I am correct on the absence of such viewer then you can't do it
(yet).

You could get the appearance you wanted with XSLT to create the HTML/XHTML
and CSS to provide the emphasis on certain elements. Simply apply an XSLT
template to contain the content of what I am calling the <qualifier> element
in HTML  tags.

If you only want to style XML on the web then CSS (despite browser
inconsistencies in implementation) will do quite a lot of what you need, when
combined with XSLT to produce HTML/XHTML.

Alternatively, you could style your XML source directly but that limits your
options at present - essentially to use on IE5.

Let's say you wanted to have the output which includes

<qualifier>non-obstructive</qualifier>

then you could achieve the kind of appearance you are seeking by using a CSS
which include the following rule:

qualifier {font-weight:bold;}

assuming you already have font family and font size appropriately set for the
containing text/elements.

I hope that helps.

Andrew Watt

Hi,

I am trying to use the xmlns:fo="http://www.w3.org/1999/XSL/Format"
in my stylesheet to transform to HTML pages.
Is this possible at this point?? I am using the latest msxml3.dll.
I am also going to try and use this for ordered lists and items..
As of right now I am using a template for the emphasis tags:
<xsl:template match="EMPHASIS">
	 <b>
		 <xsl:apply-templates/>
	 </b>
</xsl:template>
But would like to use:
<xsl:template match="EMPHASIS">
	 <fo:inline-sequence font-weight="bold">
         <xsl:apply-templates/>
	 </fo:inline-sequence>
</xsl:template>


I appreciate any help,
Heather Gazdik


This is what I get so far:
XML file:
<?xml version="1.0" encoding="UTF-8"?>
<QUESTION ID="q2-3">
	 <PARA>What is Ogilvie's syndrome?</PARA>
	 <RESPONSES>
		 <ANSWER Answer="Correct">
			 <PARA>Massive <EMPHASIS EMPH-
TYPE="bold">nonobstructive</EMPHASIS> colonic dilatation</PARA>
		 </ANSWER>
	 </RESPONSES>
</QUESTION>

XSL file:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format">

<xsl:template match="/">
<html>
	 <head>
		 <body>
			 <p>
			 <a href="#answer"><xsl:value-of
select="QUESTION/PARA"/></a>

	 </p><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br
/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>

	 <br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><b
r/>

			 <xsl:apply-templates
select="QUESTION//ANSWER"/>
	 <p>
      	  <input type="button" value="PREV" name="btnPrevious"
onClick="getPrevious()"/>
        <input type="button" value="NEXT" name="btnNext"
onClick="getNext()"/>
        <input type="button" value="MISSED" name="btnMissed"
onClick="getMIssed()"/>
        <input type="button" value="TOPICS" name="btnMissed"
onClick="getTopics()"/>

   	  </p>
	 </body>
	 </head>
</html>

</xsl:template>

<xsl:template match="QUESTION/ANSWER">
				 <xsl:apply-templates
select="EMPHASIS"/>
				 <a name="answer"><xsl:value-of
select="PARA"/></a>
</xsl:template>
<xsl:template match="EMPHASIS">
	 <fo:inline-sequence font-weight="bold">
		 <xsl:apply-templates/>
	 </fo:inline-sequence>
</xsl:template>


</xsl:stylesheet>

HTML source:

<html xmlns:fo="http://www.w3.org/1999/XSL/Format">
<head>
<META http-equiv="Content-Type" content="text/html; charset=UTF-16">
<body>
<p><a href="#answer">What is Ogilvie's syndrome?
</a></p><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><b
r><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br>Massive <fo:inline-sequence font-
weight="bold">nonobstructive</fo:inline-sequence> colonic
dilatation<p><input type="button" value="PREV" name="btnPrevious"
onClick="getPrevious()"><input type="button" value="NEXT"
name="btnNext" onClick="getNext()"><input type="button"
value="MISSED" name="btnMissed" onClick="getMIssed()"><input
type="button" value="TOPICS" name="btnMissed" onClick="getTopics
()"></p>
</body>
</head>
</html>

In a message dated 14/01/01 01:44:12 GMT Standard Time, inhorbit@...
writes:

> Let's start a poll!  Who wants to move this group to Usenet?  hehe,

Hi Jon, I assume you joined from the SVG-Developers group? ... Just for other
members here who won't be familiar with the background, the SVG-Developers
list on eGroups is debating the possibility of moving to Usenet - in part to
provide a permanent public archive / learning resource on SVG.

>  No, appears that the majority likes this format well enough to keep
>  it.  I could take it or leave it now that I'm on DSL.  If you want
>  search capability just sign up for the daily archive to be sent and
>  then just save each one into its own directory which you can search
>  later.  Requires some personal administration but it has been a work-
>  around for me.
>
>  Andrew, great idea for a group.  Thanks.
>
>  Jon

Jon, the great advantage of eGroups.com from my point of view is that it was
literally a matter of minutes from finally deciding to set up an XSL-FO group
to it being in existence. Contrast that with Usenet where there is a fairly
complex and drawn out process, which can last a minimum of weeks. In
addition, on Usenet, to begin that process to create a new group e.g. for
XSL-FO you have to demonstrate an existing Usenet community who are _already_
posting in volume on XSL-FO.

I thought it was better to provide an XSL-FO focus now for the small (?) but
growing XSL-FO community.

BTW Jon, are you a "friend of Ed"? :)

Andrew Watt

Just an invitation to members to follow Edd Dumbill's lead. Please
feel free to add useful links to the Links page.

Thanks Edd. XMLHack.com is a great resource. I have been using it for
many months and its range of XML coverage is excellent.

If your link falls clearly into the categories represented by the
folders please post it in the appropriate folder(s). I think
XMLHack.com is so multi-dimensional it is properly placed where it is.

I have just added a new folder for "XSL-FO with SVG" sites. At the
moment I don't know of (or can't immediately think of) any sites with
useful coverage on this. But I do think there will be more
exploration of the interaction of those two fascinating technologies.
If anyone knows of any XSL-FO with SVG site please feel free to add
it to the folder.

When posting a new link, please take a moment to email the group if
you think the link is particularly good or will be particularly
interesting to certain members. It just gives the group a "heads up"
that an interesting new link has been added.

How to add links?

1. Login with eGroups.com If you joined using the email subsription
address you will have a password but probably won't know it. Attempt
to login, admit to having "forgotten" your password and it will be
emailed to you.
2. Once successfully logged in, go to the XSL-FO group page. Simply
click on the XSL-FO name on the "MyGroups" page.
3. Then choose the link to the Links page. The link is currently part
way down the left column.

Andrew Watt

Let's start a poll!  Who wants to move this group to Usenet?  hehe,

No, appears that the majority likes this format well enough to keep
it.  I could take it or leave it now that I'm on DSL.  If you want
search capability just sign up for the daily archive to be sent and
then just save each one into its own directory which you can search
later.  Requires some personal administration but it has been a work-
around for me.

Andrew, great idea for a group.  Thanks.

Jon

Hello,

Just thought I would put my two cents in and say that:
Elliotte Rusty Harold has a chapter on line about XSL-FO.
He updates the page fairly often. So here is the address.

(it shows how to embed an image into a pdf file :-)

http://www.ibiblio.org/xml/books/bible/updates/15.html

have fun

Robert A. DiBlasi

[I have cross-copied this reply to both the SVG-developers and XSL-FO groups,
since it may be of interest in the archives for new members on each group.]

Tobias,

Thanks for the questions. I will attempt to give some sort of answer. Please
accept that it is highly compressed. Chris and Jon on SVG-Developers or some
members on XSL-FO could probably comment further.

In a message dated 12/01/01 11:32:48 GMT Standard Time, tobiasreif@...
writes:

> Andrew,
>
>  I have to admit that I don't know anything about
>  XSL-FO; could you help me out?

XSL-FO is, broadly, the XML-based styling equivalent of CSS. As the SVG CR
indicates SVG can be styled using either CSS or XSL-FO (sometimes called
"XSL"). See Section 6 of the CR. The mention of XSL is VERY brief and says
virtually nothing about how it is all to be made to work together. As far as
I remember there is no sample XSL-FO code in the SVG CR.

Go to www.w3.org and follow the XSL link at the lower left to get access to
background documents on XSLT and XSL-FO.

XSL, as I see it, is XSL Transformations (XSLT) plus XSL Formatting Objects
(XSL-FO). Some use "XSL" to refer to XSL-FO only which I view as confusing.

>  Which are the fields it is useful for?

Styling XML - potentially on "all" platforms. In principle if you are using
XML-based data it can be transformed and styled using XSLT and XSL-FO for
output on the web and on paper.

Given the complexity of XSL Formatting don't expect an XSL Formatter in your
web-enable mobile phone any time soon. :) But I could be proved wrong. :)

>  What exactly is it developed for?

Styling XML.

>  Where is it's homepage?

http://www.w3.org/Style/XSL/

>  "What can XSL-FO do that SVG can't do?"

It isn't an "either or" situation. The future, I think, is "both and". :)

>  Copuld it be desribed as PDF-style XML-namespace?

Loosely, yes. But very loosely. :)

>  Are there XSL-stylesheets to transform static SVGs to
>  XSL-FO?

As I said it isn't really an "either or" situation, as I see it.

>  http://xml.apache.org/fop/ says:
>  "Another secondary goal is to promote the conversion
>  of SVG into PDF. The most natural mechanism for doing
>  so is within fo:instream-foreign-object FO's. The
>  powerful graphics offered by both SVG and PDF are a
>  natural fit, and it is desirable that FOP natively
>  supports an SVG content processor for the
>  fo:instream-foreign-object. "
>     Why transform SVG to PDF, if XSL-FO is the better
>  PDF; or isn't it?

As of this moment XSL-FO isn't (yet) the "better PDF". But it may be before
too much time has passed. PDF tools are pretty mature and reliable. XSL-FO
tools are only emerging. Not surprising since the XSL-FO spec is still at CR
stage.

I suggest you use FOP for another purpose if you want to begin playing with
XSL-FO. FOP provides a "beginners" download which includes a range of sample
XSL-FO files. They are intended for conversion to PDF but you can also view
them directly in an XSL Formatter e.g. the Antenna House XSL Formatter at
www.antennahouse.com

Using that route, you can at least play with XSL-FO even if you know nothing
about XSLT or XSL-FO. But, obviously, to do anything constructive you (or a
colleague) will need to master XSLT and XSL-FO if you want to convert the
structure of XML source documents or apply style to them.

Of course, you can use XSLT to produce SVG documents. You can use XSLT to
produce XSL-FO. And, with correct use of namespaces and the development of
suitable tools you can convert / style XML source to a combination of XSL-FO
/ SVG which a future "multi-capable" XML browser will be able to display in
all sorts of impressive ways.

Six or twelve months from now I would expect to integration of SVG and XSL-FO
to be a very live issue.

Thus goes my leap into the (not very distant) future.

I hope that helps.

Andrew Watt

Take a look at this site which has useful XSL-FO material:

http://zvon.org/xxl/xslfoReference/Output/index.html

Andrew Watt

I have just added the URL for the Antenna House XSL Formatter preview
release to the Links page for the group.

Please feel free to add other useful XSL-FO links to the Links page
which can be found at:

http://www.egroups.com/links/XSL-FO/

I am not certain but you may need to be both a group member and
logged in to eGroups.com to add a link to the page.

Any web sites describing or offering XSL-FO tools, XSL-FO tutorials
or XSL-FO example code would be suitable for addition to the Links
page.

Andrew Watt

Since I posted my query about available XSL browsers I have been made aware
of the Antenna House XSL Formatter.

It is a major step forward, IMHO.

Visit the URL at http://www.antennahouse.com/xslformatter.html for relevant
information.

It is a good feeling to be able to see XSL-FO directly on screen.

I think that tools like the Antenna House XSL Formatter will push the use of
XSL-FO forward rapidly over the next few months. Immediate feedback from
on-screen display of XSL-FO is a great stimulus to further creative
exploration.

Andrew Watt

I was wondering if any list member was aware of any browser which is able to
display any XSL-FO natively. I am not necessarily seeking any full
implementation. A partial implementation would also be of interest.

If agreeing to an NDA would gain access to any alpha or beta code then I
would be happy to accept that.

Any replies on and off list would be appreciated.

Andrew Watt

Test - The original message posted to the list didn't arrive in my mail box
after 12 hours.

Hopefully this will be more successful.

Andrew Watt

Welcome, if you are reading this post at some later date using the
XSL-FO list archives.

Please feel free to join and actively participate on the XSL-FO list.

As time goes by we hope to build up an information resource about XSL-
FO tools as they become available.

The immediate purpose ... to confirm that I can post to the XSL-FO
list which I have just set up today.

Andrew Watt