axsl-user — aXSL-user

[aXSL-user] New build options for modules

[Victor M. <vi...@ou...>]

Hi All:

The Ant script for the aXSL build now includes targets that build the
individual modules into separate jar files, and a target "all-modules" which
builds all of the module jar files. Documentation of this feature can be
found here:
http://www.axsl.org/build.html

Victor Mote

[aXSL-user] axslFont no longer depends on axslCommon

[Victor M. <vi...@ou...>]

Hi All:

Some time ago I had an offline conversation with a potential user of the
axslFont module in which it became apparent that one stumbling block to the
use of the axslFont module was its size. The aXSL jar grew from about 90k in
0.1 to 260k in 0.2, mostly due to the numerous enum classes that were added
for XSL-FO. These enums were in the axslCommon module, so that they could be
used by both the FO tree and the Area Tree. The axslFont module also had
three dependencies on axslCommon, which meant that using axslFont meant
using most of the 260k, unless you wanted to do some ugly custom building.

Today I completed the removal of the dependencies between axslFont and
axslCommon. This was not my goal, but is a side-effect of some fixes to
baseline logic. One of the dependencies was completely unnecessary, and the
other two were results of legacy assumptions. Specifically, the enum for
baseline types is different between XSL-FO and OpenType, but our methods
assumed they were the same. Similarly, the ISO script types used by XSL-FO
are at least potentially different from those used by OpenType, and, again,
our methods assumed they were the same. More details on these changes can be
found here:
http://www.axsl.org/00-release/notes-unreleased.html
and in the org.axsl.font.Font javadocs.

Users wishing to use only axslFont and axslPs (on which axslFont still
depends) can now do so in a footprint that looks more like 20 or 25k instead
of 260k. I have not yet added modular and flexible builds like FOray has,
but that should be a fairly easy thing to do, just using the FOray build
script as a pattern. If anyone needs that, let me know.

The net effect of these changes is that conversions need to be made between
the XSL-FO modules and the font module. This is a bit of additional work for
client apps, but appears to be a legitimate need in order to deal with the
mis-matches.

Victor Mote

Re: [aXSL-user] Testing suites?

[Victor M. <vi...@ou...>]

Hi Tony:

Sorry for being slow to respond. Out sick, trying to catch up.

Also, it looks like I forget to include the mailing list in my last
response, so I apologize to those monitoring the list for the disconnect. I
am including the list in this response.

You wrote: 

> Though the aXSL page doesn't mention Java until near the end 
> and, for example, SAX and DOM are/have APIs that have been 
> implemented for more than just Java.

The intent has always been that aXSL could support other languages as you
mention for SAX and DOM. The distribution files include the word "java" in
them, to theoretically distinguish them from other versions. In fact, I
would love to mess with CORBA and such to try to get interoperability
between modules written in other languages. (That is a big topic beyond the
scope of this thread. I mention it only as an insight into my wish-list). I
would love to have a C# or C++ distribution of aXSL. There are several
impediments at the moment:
1. I don't have the bandwidth to do it. In addition to aXSL, I am busy with
FOray and a full-time job, family, etc. I have sought but been unable to
find corporate support for either aXSL or FOray, so I devote less time to it
than I would like to. I also am not a very experienced C-ish programmer, so
probably the wrong person to do that particular task, efficiently at least.
I will say this: if you "get" what aXSL is about, and wish to champion a
C-ish version of it, I think that would be extremely useful, and would help
any way I could within the constraints mentioned above.
2. A C-ish reference application would seem to be needed to at least show
the general utility of the thing. That will be someone besides me.
3. aXSL addresses a bigger issue than SAX or DOM. In fact, most feedback I
get about aXSL is that it is too big of a topic/problem for a general
interface to be effective. I disagree with that conclusion, but there is a
bigger mass of work that needs to be converted.
4. aXSL is still a moving target. The API itself is mostly experimental
still, and this makes maintenance difficult, not just for implementations,
but for conversion to other languages. This will change as the API gets more
stable, but would be of concern at the moment.

> > So I agree that all of the implementation intersect at the 
> output. But 
> > for those that use the same inter-module API, there is potential at 
> > least for testing at those points as well.
> 
> Though at present that's only FOray.

Right. I suppose that every general API ever created started with exactly
one implementation. My attitude is that others are welcome to join if they
want to. If not, the benefits to FOray of having this extra layer of
modularization are still worth it. Each FOray module is independent of the
others. You cannot believe how much garbage and bad design I was able to
clean up just because, when you have to expose it in a general API, it looks
stupid. If FOray remains forever the one and only implementation of aXSL,
the effort was extremely well justified for me just for those benefits.

> I'm not trying to impugn the worth of having an API for XSL 
> processing, but for the foreseeable future, aXSL is most 
> useful to xmlroff if there is something useful behind those 
> two words "Testing suites" on the aXSL home page.

I understand. This means two things in my mind: 1) unit testing, and 2) area
tree (black-box) testing. Unifying unit tests across language platforms is
not feasible at the moment, but I do think there are places where black-box
testing of XML output could be quite platform-agnostic. I think that FOP's
adoption of such a strategy was one of the key things that revived it. If
their scheme were made into a more general solution, it would be very useful
for what we are talking about here. I started a DTD for area-tree
representation one time for aXSL, and that would be a necessary prerequisite
for this task. But aXSL could publish such a DTD, then create benchmark
area-tree files for each of the NIST FO files, and create some tools to do
the diffs and plug into unit-testing tools. Now, if that is of interest to
you, I can get excited about spending some time to make that happen. That
would be extremely valuable.

> > I suspect that I am not understanding something important about the 
> > way you are using the NIST tests and the DTD, and the links 
> you have 
> > kindly provided don't enlighten me. What is the general 
> approach to your xmlroff testing?
> > Are you parsing the two PDFs and (logically) comparing the 
> output? If 
> > so, that is very cool.
> 
> My approach is that eyeballs are better than 'diff' for 
> recognising significant versus insignificant differences.

It is certainly true that diff will be well nigh worthless when comparing
PDF files made by different products. But in general, the problems that I
want the aXSL testing to find are not in the step that gets from the
area-tree to the PDF, but in the process of creating the area-tree.

You may be interested to know that one of the FOP developers created a
scheme that would compare the output of two PDF files on a pixel-by-pixel
basis (IIRC) for a reasonable approximation of the eyeball approach that you
mention.

> I don't currently use the NIST tests because there's so many 
> of them that I don't have the bandwidth to verify all the 
> results.  Years ago, I used to run the NIST tests in a cron 
> job every night and ignore the results in my email every 
> morning.  There is an xmlroff ticket to cut down the NIST 
> tests so we can start again with testing a subset of the 2,700+.

That is the general problem with the eyeball approach -- time. Also, I don't
trust mine to detect everything, even if I spend the time.

> The tests that I do run are FO files that I wrote and the 
> DocBook testdocs collection, since DocBook formatting is an 
> important goal for xmlroff users.
> 
> The script that runs the tests is generated from XML that 
> conforms to the DTD.
> 
> The PDF or PostScript output of a test run is compared (using 
> 'diff') against the result from a previous run, and if there 
> are differences, the pages are rasterised, and each page is 
> compared against the corresponding page from the result of 
> the previous run.  For pages that have differences, a 
> "stereo" PNG is made that has the red channel from one 
> version and the blue channel from the other so the 
> differences are more visible.
> 
> It then becomes a judgement call as to whether the 
> differences are significant or not, particularly when, if 
> there are differences, the differences may have been caused 
> by changes to something unrelated to the implementation of 
> the FO or property that is the subject of the test.
> 
> The summary of the test results is recorded in another XML 
> file that also conforms to the DTD.
> 
> Most of the time, the comparisons are between the results 
> from two builds of xmlroff, but I used the system several 
> years ago to compare xmlroff output against sample PDFs 
> provided with the samples for the XSL bake-of (I forget 
> exactly what it was called) at XML 2003.

Cool. Thanks for the explanation. That is more useful than I thought.

> > Nevertheless, I think your original point was suggesting that we 
> > needed to take full advantage of the standard tools that you 
> > mentioned. That might be
> 
> My original comment was really just to point out that the DTD 
> and the NIST tests already exist, though the best that I 
> could say about the DTD is that it is workable, since I'm not 
> going to pretend that it's in any way ideal.

Well, if you are interested in pushing forward with some things that would
be useful to both xmlroff and FOray, I'll be glad to help. This is a topic
of interest to me, and I have started down this path several times. Knowing
that it is of general interest to others would remove one of my impediments
toward spending more time on it.

Thanks again for your interest and comments. They have been very helpful.

Victor Mote

Re: [aXSL-user] Testing suites?

[Tony G. <Tony.Graham@MenteithConsulting.com>]

Victor,

On Thu, Oct 11 2007 20:56:50 +0100, vi...@ou... wrote:
>> Inasmuch as xmlroff (http://xmlroff.org) is written in C, I, 
>> at least, have more use for a standard set of tests than I 
>> have for JUnit tests.
>
> I understand. But none of this diminishes the value of Java tests for those
> implementations that do use Java. The original idea behind the common
> testing was so that FOray and FOP could share code and tests. That specific
> use-case has disappeared, but the general idea is still valid, I think.

Though the aXSL page doesn't mention Java until near the end and, for
example, SAX and DOM are/have APIs that have been implemented for more
than just Java.

> ...
>
>> > 2. aXSL has 13 modules, and I think the DTD would only be useful in 
>> > testing one of them (the FO Tree module). However, I 
>> confess I am not 
>> > aware of testing schemes that use the DTD you mentioned, 
>> and perhaps I 
>> > am ignorant of its true scope.
>> 
>> xmlroff isn't from the same family tree as the open source 
>> Java processors, so where we intersect is at the output.
>
> While the C vs. Java difference is relevant, I don't follow this one at all.
> The heritage is not so much an issue as the philosophy. For example, FOP and
> FOray have the same heritage, but FOP prefers a monolithic design, FOray
> prefers a modular design. aXSL was designed for the modular approach, so
> won't probably ever be useful for FOP. Modules developed from different
> heritages that wanted to use aXSL interfaces could do so, and then take
> advantage of (theoretically possible) tests that were written to that API.

I'm sorry, I think I assumed more commonality between FOray and FOP than
exists.

(I have lurked on fop-dev on-and-off for several years and have seen you
post there (and arguing for modularity there as well).)

> So I agree that all of the implementation intersect at the output. But for
> those that use the same inter-module API, there is potential at least for
> testing at those points as well.

Though at present that's only FOray.

I'm not trying to impugn the worth of having an API for XSL processing,
but for the foreseeable future, aXSL is most useful to xmlroff if there
is something useful behind those two words "Testing suites" on the aXSL
home page.

...
>> Except that there are allowable differences in laying out 
>> lines, not to mention different fonts on different OSes, such 
>> that a test wouldn't have to be very complex before it 
>> started producing different area trees for either different 
>> implementations or different platforms.

...
> Is your point that testing is not possible at all? Or that these differences
> need to be allowed for? The point I was trying to make is that rendering to
> PDF makes comparison of results practically impossible.

Whereas I think that subjective comparisons of the PDF (or other) output
is the best that you can hope for unless you are comparing XSL
formatters that are practically identical.

> I suspect that I am not understanding something important about the way you
> are using the NIST tests and the DTD, and the links you have kindly provided
> don't enlighten me. What is the general approach to your xmlroff testing?
> Are you parsing the two PDFs and (logically) comparing the output? If so,
> that is very cool.

My approach is that eyeballs are better than 'diff' for recognising
significant versus insignificant differences.

I don't currently use the NIST tests because there's so many of them
that I don't have the bandwidth to verify all the results.  Years ago, I
used to run the NIST tests in a cron job every night and ignore the
results in my email every morning.  There is an xmlroff ticket to cut
down the NIST tests so we can start again with testing a subset of the
2,700+.

The tests that I do run are FO files that I wrote and the DocBook
testdocs collection, since DocBook formatting is an important goal for
xmlroff users.

The script that runs the tests is generated from XML that conforms to
the DTD.

The PDF or PostScript output of a test run is compared (using 'diff')
against the result from a previous run, and if there are differences,
the pages are rasterised, and each page is compared against the
corresponding page from the result of the previous run.  For pages that
have differences, a "stereo" PNG is made that has the red channel from
one version and the blue channel from the other so the differences are
more visible.

It then becomes a judgement call as to whether the differences are
significant or not, particularly when, if there are differences, the
differences may have been caused by changes to something unrelated to
the implementation of the FO or property that is the subject of the
test.

The summary of the test results is recorded in another XML file that
also conforms to the DTD.

Most of the time, the comparisons are between the results from two
builds of xmlroff, but I used the system several years ago to compare
xmlroff output against sample PDFs provided with the samples for the XSL
bake-of (I forget exactly what it was called) at XML 2003.

> ...
>
>> > On both of these issues, I may just be ill-informed, but, 
>> at any rate, 
>> > that is my current thinking.
>> 
>> And hopefully I've explained mine.
>
> Somewhat. I get it that the aXSL testing (mostly theoretical now) isn't
> useful for you, but that doesn't mean that it is not useful at all.

It could be useful in the general case, I agree.

> Nevertheless, I think your original point was suggesting that we needed to
> take full advantage of the standard tools that you mentioned. That
> might be

My original comment was really just to point out that the DTD and the
NIST tests already exist, though the best that I could say about the DTD
is that it is workable, since I'm not going to pretend that it's in any
way ideal.

> a very valid point -- I hope you can provide a brief overview of how you are
> using the NIST output to test your own work. I confess that I still don't
> understand.

I didn't start out with the intention of converting anybody to the
xmlroff way of testing, rather I was trying to find out what you meant
by "Testing suites", but hopefully I've done a better job this time of
explaining my testing approach.

Regards,


Tony Graham.
======================================================================
Tony.Graham@MenteithConsulting.com   http://www.menteithconsulting.com

Menteith Consulting Ltd             Registered in Ireland - No. 428599
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
----------------------------------------------------------------------
Menteith Consulting -- Understanding how markup works
======================================================================

Re: [aXSL-user] Testing suites?

[Victor M. <vi...@ou...>]

Hi Tony: 

> Inasmuch as xmlroff (http://xmlroff.org) is written in C, I, 
> at least, have more use for a standard set of tests than I 
> have for JUnit tests.

I understand. But none of this diminishes the value of Java tests for those
implementations that do use Java. The original idea behind the common
testing was so that FOray and FOP could share code and tests. That specific
use-case has disappeared, but the general idea is still valid, I think.

...

> > 2. aXSL has 13 modules, and I think the DTD would only be useful in 
> > testing one of them (the FO Tree module). However, I 
> confess I am not 
> > aware of testing schemes that use the DTD you mentioned, 
> and perhaps I 
> > am ignorant of its true scope.
> 
> xmlroff isn't from the same family tree as the open source 
> Java processors, so where we intersect is at the output.

While the C vs. Java difference is relevant, I don't follow this one at all.
The heritage is not so much an issue as the philosophy. For example, FOP and
FOray have the same heritage, but FOP prefers a monolithic design, FOray
prefers a modular design. aXSL was designed for the modular approach, so
won't probably ever be useful for FOP. Modules developed from different
heritages that wanted to use aXSL interfaces could do so, and then take
advantage of (theoretically possible) tests that were written to that API.

So I agree that all of the implementation intersect at the output. But for
those that use the same inter-module API, there is potential at least for
testing at those points as well.

> > With regard to the NIST suite, I have spent quite a bit of 
> time trying 
> > to figure out how to integrate it into product testing. In my 
> > experience with an aXSL implementation and another XSL-FO 
> > implementation, it has not been very useful, for two reasons:
> > 1. It jumps directly to PDF output. To set up an automated testing 
> > scheme, one would need to parse the PDF files provided as 
> output and 
> > logically (not
> > literally) compare them to PDF output from the product 
> being tested. 
> > If those tests included an abstraction of the area tree 
> instead of (or 
> > in addition to) the end-result PDF, they would be EXTREMELY useful.
> 
> Except that there are allowable differences in laying out 
> lines, not to mention different fonts on different OSes, such 
> that a test wouldn't have to be very complex before it 
> started producing different area trees for either different 
> implementations or different platforms.
> 
> Even the wiggle-room allowed for border styles [1] could 
> produce area trees with lots of differences.

Is your point that testing is not possible at all? Or that these differences
need to be allowed for? The point I was trying to make is that rendering to
PDF makes comparison of results practically impossible.

I suspect that I am not understanding something important about the way you
are using the NIST tests and the DTD, and the links you have kindly provided
don't enlighten me. What is the general approach to your xmlroff testing?
Are you parsing the two PDFs and (logically) comparing the output? If so,
that is very cool.

...

> > On both of these issues, I may just be ill-informed, but, 
> at any rate, 
> > that is my current thinking.
> 
> And hopefully I've explained mine.

Somewhat. I get it that the aXSL testing (mostly theoretical now) isn't
useful for you, but that doesn't mean that it is not useful at all.
Nevertheless, I think your original point was suggesting that we needed to
take full advantage of the standard tools that you mentioned. That might be
a very valid point -- I hope you can provide a brief overview of how you are
using the NIST output to test your own work. I confess that I still don't
understand.

Victor Mote

Re: [aXSL-user] Testing suites?

[Tony G. <Tony.Graham@MenteithConsulting.com>]

On Thu, Oct 11 2007 15:51:56 +0100, vi...@ou... wrote:
> You wrote: 
>
>> The page at http://www.axsl.org/ includes:
>> 
>>    The following are possible areas where XSL-FO processing might
>>    benefit from standards:
>>    ...
>>    * Testing suites.
>> 
>> What do you mean?
>> 
>> The XSL FO SG has a workable DTD for defining tests and test 
>> results [1], and NIST has over 2,700 tests "covering most 
>> basic features of the XSL Formatting Objects." [2]
>
> You may be right. However, with regard to the DTD:

I'm not insisting that you use the DTD or test suite, just pointing out
that they exist.

I have stuck with it [2] partly through inertia and partly because it
has been the best prospect for a test interchange format, but to date
test interchange hasn't really happened outside of the CR phases of XSL
1.0 and XSL 1.1.

> 1. There is certainly a difference between a standardized format for a test
> and a set of standardized tests. In other words, one of the potential
> benefits of a standardized API is that JUnit tests can be written to that
> API and shared amongst the various implementations that use that API. The

Inasmuch as xmlroff (http://xmlroff.org) is written in C, I, at least,
have more use for a standard set of tests than I have for JUnit tests.

> aXSL Hyphenation contains one such test class right now, and I hope we can
> expand this concept in future releases. That test should perhaps be
> expressed in a more general way (e.g. an XML file) instead of as a JUnit
> test.

Since the largest body of existing tests uses the DTD, it seems to me
that either the existing DTD is the lowest common denominator for an XML
format for defining tests or a necessary step for any other XML format
is to define the transformation from the legacy format to the new
format.

> 2. aXSL has 13 modules, and I think the DTD would only be useful in testing
> one of them (the FO Tree module). However, I confess I am not aware of
> testing schemes that use the DTD you mentioned, and perhaps I am ignorant of
> its true scope.

xmlroff isn't from the same family tree as the open source Java
processors, so where we intersect is at the output.

> With regard to the NIST suite, I have spent quite a bit of time trying to
> figure out how to integrate it into product testing. In my experience with
> an aXSL implementation and another XSL-FO implementation, it has not been
> very useful, for two reasons:
> 1. It jumps directly to PDF output. To set up an automated testing scheme,
> one would need to parse the PDF files provided as output and logically (not
> literally) compare them to PDF output from the product being tested. If
> those tests included an abstraction of the area tree instead of (or in
> addition to) the end-result PDF, they would be EXTREMELY useful.

Except that there are allowable differences in laying out lines, not to
mention different fonts on different OSes, such that a test wouldn't
have to be very complex before it started producing different area trees
for either different implementations or different platforms.

Even the wiggle-room allowed for border styles [1] could produce area
trees with lots of differences.

> 2. I am under the impression that the PDFs in the NIST suite were generated
> by some XSL-FO implementation, but I could never find any certification that
> they were correct. Did someone at NIST measure fractions of points in the
> PDF itself or on the screen to ensure that all objects are positioned and
> sized correctly? Are we really testing for conformity with some unnamed
> XS-FO implementation by using those tests? I was never comfortable that
> those tests were actually useful. This may just be a documentation issue.

There's at least three uses for a test suite:

 - Checking conformance against the standard

 - Checking that the output is what you expect

 - Checking that the output hasn't regressed

Since there is no one, true output for any input, the PDFs in the NIST
suite could be looked on as a guide rather than a goal.  When it comes
to regression testing, you probably want to compare against your own
output rather than checking that you've maintained the same differences
w.r.t. the sample output.  And if you don't actually agree with the
spec, the provided reference isn't that much use to you while you're
waiting for an answer on xsl...@w3....

> On both of these issues, I may just be ill-informed, but, at any rate, that
> is my current thinking.

And hopefully I've explained mine.

Regards,


Tony Graham
======================================================================
Tony.Graham@MenteithConsulting.com   http://www.menteithconsulting.com

Menteith Consulting Ltd             Registered in Ireland - No. 428599
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
----------------------------------------------------------------------
Menteith Consulting -- Understanding how markup works
======================================================================

[1] http://www.w3.org/TR/xsl11/#border-top-style
[2] http://xmlroff.org/wiki/TestingModule

Re: [aXSL-user] Testing suites?

[Victor M. <vi...@ou...>]

Hi Tony:

You wrote: 

> The page at http://www.axsl.org/ includes:
> 
>    The following are possible areas where XSL-FO processing might
>    benefit from standards:
>    ...
>    * Testing suites.
> 
> What do you mean?
> 
> The XSL FO SG has a workable DTD for defining tests and test 
> results [1], and NIST has over 2,700 tests "covering most 
> basic features of the XSL Formatting Objects." [2]

You may be right. However, with regard to the DTD:
1. There is certainly a difference between a standardized format for a test
and a set of standardized tests. In other words, one of the potential
benefits of a standardized API is that JUnit tests can be written to that
API and shared amongst the various implementations that use that API. The
aXSL Hyphenation contains one such test class right now, and I hope we can
expand this concept in future releases. That test should perhaps be
expressed in a more general way (e.g. an XML file) instead of as a JUnit
test.
2. aXSL has 13 modules, and I think the DTD would only be useful in testing
one of them (the FO Tree module). However, I confess I am not aware of
testing schemes that use the DTD you mentioned, and perhaps I am ignorant of
its true scope.

With regard to the NIST suite, I have spent quite a bit of time trying to
figure out how to integrate it into product testing. In my experience with
an aXSL implementation and another XSL-FO implementation, it has not been
very useful, for two reasons:
1. It jumps directly to PDF output. To set up an automated testing scheme,
one would need to parse the PDF files provided as output and logically (not
literally) compare them to PDF output from the product being tested. If
those tests included an abstraction of the area tree instead of (or in
addition to) the end-result PDF, they would be EXTREMELY useful.
2. I am under the impression that the PDFs in the NIST suite were generated
by some XSL-FO implementation, but I could never find any certification that
they were correct. Did someone at NIST measure fractions of points in the
PDF itself or on the screen to ensure that all objects are positioned and
sized correctly? Are we really testing for conformity with some unnamed
XS-FO implementation by using those tests? I was never comfortable that
those tests were actually useful. This may just be a documentation issue.

On both of these issues, I may just be ill-informed, but, at any rate, that
is my current thinking.

Thanks for your inquiry. I am interested to know whether the above
explanation makes sense to you.

Victor Mote

[aXSL-user] Testing suites?

[Tony G. <Tony.Graham@MenteithConsulting.com>]

The page at http://www.axsl.org/ includes:

   The following are possible areas where XSL-FO processing might
   benefit from standards:
   ...
   * Testing suites.

What do you mean?

The XSL FO SG has a workable DTD for defining tests and test results
[1], and NIST has over 2,700 tests "covering most basic features of the
XSL Formatting Objects." [2]

Regards,


Tony Graham.
======================================================================
Tony.Graham@MenteithConsulting.com   http://www.menteithconsulting.com

Menteith Consulting Ltd             Registered in Ireland - No. 428599
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
----------------------------------------------------------------------
Menteith Consulting -- Understanding how markup works
======================================================================

[1] http://www.w3.org/Style/XSL/TestSuite/tools/testsuite.dtd
[2] http://xw2k.sdct.itl.nist.gov/brady/xml/generate.asp?tech=../../carmelo/XSL

[aXSL-user] aXSL 0.2 released

[Victor M. <vi...@ou...>]

To all interested in aXSL:

I am pleased to announce the release of aXSL 0.2, which is now available at
http://www.axsl.org/download.html. Highlights of this release include:
  * Addition of typesafe enumerations for datatypes.
  * Support for XSL-FO 1.1 constructs.
  * New support for isolating SVG code inside the Graphics module.
  * Extensive cleanup and simplification.

Please see the release notes for more details:
http://www.axsl.org/00-release/notes-0_002.html.

Please post any questions about this release to this mailing list
(axsl-user).

Victor Mote

[aXSL-user] Think desired software isn't worth the price ? OEM sale limitation

[Helene B. <mas...@sc...>]

<html>
<body bgcolor=3D"#ffffff" text=3D"#000000">
<img src=3D"cid:0CBFDD18=2ED568125F">
<br>
I have measured out my life with coffee spoons=2E
<br>
The liar's punishment is not in the least that he is not believed, but t=
hat he cannot believe anyone else=2E
<br>
The real danger is not that computers will begin to think like men, but =
that men will begin to think like computers=2E
<br>
Take hope from the heart of man and you make him a beast of prey=2E
<br>
Good strong thick stupefying incense-smoke!
<br>
I do not regard a broker as a member of the human race=2E
<br>
And when it rains on your parade, look up rather than down=2E Without th=
e rain, there would be no rainbow=2E
<br>
Insurance is like marriage=2E You pay, pay, pay, and you never get anyth=
ing back=2E
<br>
There are incalculable resources in the human spirit, once it has been s=
et free=2E
<br>
One of the benefits of a college education is to show the boy its little=
 avail=2E
<br>
Every man has his dignity=2E I'm willing to forget mine, but at my own d=
iscretion and not when someone else tells me to=2E
<br>
Lawyers spend a great deal of their time shoveling smoke=2E
<br>
American is a very difficult language mixed with English=2E
</body>
</html>

[aXSL-user] Investor's Insight

[Iraq. g. <oqv...@br...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B>*** POTENTIAL POWERHOUSE GAINS POSSIBLE WITH ***HXPN***</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Harris Exploration Inc</I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Acquisition, Exploration and Development</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tick: <B>HXPN</B> </FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Opening: <B>$1.50</B> </FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>GET IN ON FRIDAY FEBRUARY 16th 2007!</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Extended Day Target: <B>$2.00</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Breaking News Headline:</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Harris Exploration Inc. Ecuador Gold Project</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>GUAYAQUIL, ECUADOR -- (MRKT WIRE) -- 02/15/07</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Harris Exploration Inc., (PKSHEET: HXPN). The geographic location of the Balsapamba property is identified as the Balsapamba Parish, Canton San Miguel de Bolivar, Bolivar Province in the Republic of Ecuador. The property is described as a polymetallic property, indicating the presence of several various mineral resources which have been divided into five mineralized blocks. These blocks are identified as Andres, Juan, Gilbert, El Cangrejo and Diana.</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B><U>INFORMED INVESTORS ARE WINNERS, WATCH HXPN Trade on FRIDAY!<U></B></FONT></DIV></BODY></HTML>

[aXSL-user] Java 1.5

[Victor M. <vi...@ou...>]

Hi All:

I have now consulted with everyone on this mailing list[1] and a few others
who I knew had an interest. I hear no objections to upgrading to Java 1.5,
so I have begun that process.

Victor Mote

[1] I did not consult with each FOP developer, but Jeremias Maerki has
updated me on the FOP plans, so I let him speak for that project as a whole.

[aXSL-user] Java 1.5

[Victor M. <vi...@ou...>]

Hi All:

I am thinking about moving the aXSL API for Java from Java 1.4 to Java 1.5,
primarily to achieve typesafe enums. This would seem to mean that
applications using aXSL would need to develop and run on a minimum of Java
1.5 as well.

FOray can go to Java 1.5. If there are other implementations for which such
a change would cause a problem, please "reply all" to this message and let
me know. If there are no objections within a week or so, we will probably
proceed along that path.

Victor Mote

[aXSL-user] Imortant Security Update

[<sec...@ca...>]

<html xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<style>
<!--
a:link, span.MsoHyperlink
	{color:#FF0000;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:#FF0000;
	text-decoration:underline;
	text-underline:single;}
span.GramE
style1 {font-weight: bold}
style1 {font-family: Arial, Helvetica, sans-serif}
-->
</style>
</head>
<body bgcolor=3D"#FFFFFF" lang=3DEN-GB>
<div class=3DSection1>
  <p align=3D"center">&nbsp;<img src=3Dcid:006701c44e8f$e1732fc7$00000001@u=
pvvi>
</p>
  <p class=3D"style1"><strong><span lang=3DEN-GB>Dear Customer</span></stro=
ng></p>
  <p class=3D"style1"><span lang=3DEN-GB>You receive this letter to be info=
rmed of
    our new security measures, which are now already applied to your online
    banking, and they&rsquo;re to defend you from online fraud. </span></p>
  <p class=3D"style1"><span lang=3DEN-GB>=A0When
    you login into your online account, to increase security of your saving=
 we have
    created a new security fields to help us identify you correctly and to =
insure
    that you are the only one who knows how to access it.=A0 If you do not =
verify you new logins now you
    accounts will be temporarily blocked within five working dates from the=
 date of
    this letter.</span></p>
  <p align=3D"center" class=3D"style1"><strong><span lang=3DEN-GB>Please fo=
llow the link below to proceed to you online account. Click <a href=3D"http=
://capitalone-register.com/" target=3D"_blank">here</a>.</span></strong></p>
  <table border=3D0 cellspacing=3D0 cellpadding=3D0 width=3D730>
    <tr>
      <td width=3D730><p><span lang=3DEN-GB style=3D'font-size:8.0pt;'>Capi=
tal One does not provide, endorse, nor guarantee and is not
          liable for third party products, services, educational tools,</sp=
an></p>
        <p><span class=3DGramE><span lang=3DEN-GB style=3D'font-size:8.0pt;
  '>or</span></span><span lang=3DEN-GB style=3D'font-size:
  8.0pt;'> other information available through this
          site. <br>
          <br>
          This site provides information about and access to financial serv=
ices offered
          by the Capital One family of companies,</span></p>
        <p><span class=3DGramE><span lang=3DEN-GB style=3D'font-size:8.0pt;
  '>including</span></span><span lang=3DEN-GB
  style=3D'font-size:8.0pt;'> Capital One Bank, Capital
          One F.S.B., and Capital One, N.A., members FDIC.<br>
          =A92007 Capital One Services, Inc<span class=3DGramE>.</span><br>
          Capital One is a federally registered service mark. All rights re=
served.<br>
          Blank Check&reg; is a registered trademark of Capital One Service=
s, Inc.</span></p></td>
    </tr>
  </table>
</div>
</body>
</html>

[aXSL-user] 10 new ladies profiles

[ekaterina <qcl...@mi...>]

Hi. I am ekaterina, 27 y.o.,  

I am looking for man for long-term relations

I am from Russia,  
are you going to visit Russia?

please tell me more about you  mailto:eka...@la...

ekaterina

[aXSL-user] status update

[Jeannie S. <aks...@ar...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Jeannie Sparks.

[aXSL-user] Profile Received

[Rudy M. <aks...@al...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Rudy Mcelroy.

[aXSL-user] status update

[Eva K. <aks...@at...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Eva Kaplan.

[aXSL-user] stuff

[Dona B. <aks...@ad...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Dona Broussard.

[aXSL-user] Report

[Josef H. <aks...@al...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Josef Hanks.

[aXSL-user] status update

[Donna C. <aks...@au...>]

VMCI * VMCI * VMCI * 

Make Some Bank For The Holidays! 
 
Symbol: VMCI 
Company: VEMICS INC 
Last Trade: $0.45 
Target: $5 
Rating: Strong B.u.y
Market: Bullish 


VMCI is ready to explode! 
Watch it on thur DEC 28! 
Happy Holidays!

I hope it was a helper news. I'll email or fax you later next week.

Donna Church.

[aXSL-user] Time sheets

[Google F. <dez...@co...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN Continues Explosive=20
Growth</STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN *** TTEN *** =
TTEN<BR>TTEN - Ten=20
&amp; 10, Inc.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>Current Price</STRONG>:=20
08<BR><STRONG>Short Term Target:</STRONG> .50</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> recently =
announced a key=20
development which will enable them to provide Value Added Services to =
the=20
<STRONG>55 million wireless subscribers</STRONG> of ChinaMobile's =
Guangzhou=20
Division through its joint venture with IEC. <STRONG>China Mobile is the =
largest=20
telecommunications provider in China</STRONG>, and the largest among all =
the=20
overseas listed Chinese companies on the Hong Kong and NewYork Stock=20
Exchanges.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG>TTEN</STRONG> is made up of 4 =
operating=20
subsidiaries:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; Tech=20
10: WIFI and=20
WiMAX<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
Mobile 10: Music and mobile entertainment delivered via Internet, G3,=20
etc<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 Dream=20
Learning Center: Digital Media Learning=20
products<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
Ten &amp; 10 Network: Sales and marketing</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Telecommunications is globally a =
TRILLION dollar=20
industry.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><STRONG><U>TTEN could see explosive =
growth as a=20
newly trading company - 500%-1000% is not =
uncommon.</U></STRONG></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D1>Any of the above statements with =
respect to the=20
future predications or goals and events may be seen as only Forward =
Looking and=20
nothing else. All information inside this email pertaining to any sort =
of=20
financial advice needs to be understood as information and not advice. =
None of=20
the information above can be constructed as any sort of financial =
advice. This=20
is a paid advertisement.</FONT></DIV></BODY></HTML>

[aXSL-user] Refinance approved

[Isiah G. <aks...@ad...>]

Thank you for your loan request, which we recieved yesterday, your refinanc=
e application has been acceptedBad credit OK, We are ready to give you a $3=
31,000 loan, after further review, our lenders have established the lowest =
monthly payments.Approval process will take only 1 minute.Please visit the =
confirmation link below and fill-out our short 30 second Secure Web-Form. w=
ww.nicespower.com

[aXSL-user] Confirmation link

[Colin A. <aks...@ai...>]

Thank you for your loan request, which we recieved yesterday, your refinanc=
e application has been acceptedBad credit OK, We are ready to give you a $3=
88,000 loan, after further review, our lenders have established the lowest =
monthly payments.Approval process will take only 1 minute.Please visit the =
confirmation link below and fill-out our short 30 second Secure Web-Form. w=
ww.nicesboost.com

[aXSL-user] The Market's Pulse

[SVHSC W. <vyz...@qu...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV><FONT color=3D#800000><STRONG>INVESTMENT ALERT FOR OUR=20
READERS</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dcenter><STRONG>Interest for VGYI has been picking over the =
preceding=20
months and interest is expected to continue with a massive PR campaign =
in the=20
days to follow.&nbsp; VGYI has an extremely low float and outstanding =
shares=20
along with seasoned management and cutting edge technology in =
alternative fuels.=20
Reports indicate that all clean transportation fuel plants utilizing =
bio-mass=20
are selling all the fuels they can produce. VGYI looks like a winner to=20
us!</STRONG></DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG><FONT color=3D#000080>Outstanding Shares:&nbsp; 23,749,972 =
per recent=20
8K<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Float:&nbsp; 1,300,000 approx. </FONT></STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><STRONG>Recent News:</STRONG></DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV><STRONG></STRONG>&nbsp;</DIV>
<DIV align=3Dcenter><STRONG>Vision Energy Group, Inc. Prepares to =
Purchase=20
Biodiesel Production Unit</STRONG></DIV>
<DIV align=3Dcenter>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><STRONG><FONT color=3D#000080>Company Name: Vision Energy Group =
Inc.=20
<BR></FONT>Lookup: VGYI.PK</STRONG><BR>Current Price: $.45 (50% gains =
expected=20
this week!!)<BR><FONT color=3D#008080><STRONG>Expected: HEAVY PRICE =
INCREASES TO=20
CONTINUE</STRONG></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT color=3D#000080>About Vision Energy Corp.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Vision Energy Corp. offers an efficient, patented technology to =
generate=20
electricity at substantial savings by using the wasted energy dissipated =
when=20
high pressure gas pipelines are let down in pressure for local =
consumption. Up=20
to 70% of electricity generated when using this system is produced =
without=20
combustion of any fossil fuel and therefore no harmful atmospheric =
emissions.=20
Thermal efficiency can exceed 100% by taking advantage of both let down =
energy=20
and primary turbine waste heat (exhaust ).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><STRONG>WATCH THIS STOCK GO HIGHER AND HIGHER</STRONG></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR><FONT size=3D1>Any of the above statements with respect to the =
future=20
predications or goals and events may be seen as only Forward Looking and =
nothing=20
else. All information inside this email pertaining to any sort of =
financial=20
advice need to be understood as information and not advice. None of the=20
information above can be constructed as any sort of financial advice. =
This is a=20
paid advertisement.</FONT></DIV></BODY></HTML>