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

RE: Need: XSL FO Schema/ .XSD/ Validator? "defined" or

Subject: RE: Need: XSL FO Schema/ .XSD/ Validator? "defined" or "variable" based on the FO Processor used.
From: "SANWAL, ABHISHEK (HP-Houston)" <abhishek.sanwal@xxxxxx>
Date: Tue, 20 Jul 2004 14:21:20 -0500
xsl fo schema
Hello All,

This is the reason why I need to have a validator mechanism.

I developed XSLs (FO flavour) for a certain FO processor. Everything was
fine and there was a little warning etc.

The same FO when fed to another FO processor flags an error which I
think very well may be because the 1st FO processor was not performing
enough validity checking compared to the second one. (I shall post
specific examples of this in another thread... meanwhile stay with the
topic)

The thing is the FO Processors messages can get cryptic at times and are
not necessarily trivial, until I plug the .FO file against a validator
(.XSD) in XMLSpy and find out "oh, I missed that <fo:xxxx> there" or
"hmm.. now what did that content piece did not get properly encapsulated
by the <fo: xxx> tag".

MY GOAL here is to write FO XSLs that will "live" through. In essence,
we should be able to PLUG in and out any FO processor that we need (I am
assuming that they will be fault free from this point on, I hope) and
have some assurance (provided by validating my .FO outputs against a
schema.. under XML Spy that allows me to track and say.. "hey.. oh! That
was the reason for that block breaking. I need to fix it in xxxx.xsl"

So, it is more for active development purposes in XmlSpy and later on
when it is running I can build an error logger around it just in case
some .FO fires an error with any given FO processor.

ALSO: I agree with Michael Kay on this. This is essentially very useful.


"I've been very pleasantly surprised by how much more quickly you find
your XSLT coding errors when the schema validation of the result
document is built in to the XSLT processing".

Although sometimes I wish I had the liberty to build off SAXON and use
Schematron and all the other good stuff I get restricted to the .NET XsL
classes at this moment. I look forward to using XSL 2.0 functional
paradigms when I get a chance. Do you think someone could port the code
to .NET. (RenderX just ported XEP to J#.NET)

Thanks,

Abhishek
____________________________________________________________

Abhishek Sanwal
HP - Houston Campus

........................................................................
..................

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, July 20, 2004 6:19 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE:  Need: XSL FO Schema/ .XSD/ Validator? "defined" or
"variable" based on the FO Processor used.

At 2004-07-20 10:26 +0100, Michael Kay wrote:
> > >Ideas on how you have used existing XSL-FO validation schemas to
trap
> > >and handle errors or anything of that type.
> >
> > Why?  In my opinion, this is wasted time.
>
>I hope to prove you wrong, Ken. I've now developed a couple of "real"
>stylesheets using the schema-aware version of Saxon - not an XSL-FO
>stylesheet, admittedly - and I've been very pleasantly surprised by how
much
>more quickly you find your XSLT coding errors when the schema
validation of
>the result document is built in to the XSLT processing.

In this, Michael, I would be pleased to be proved wrong!

>That's even with
>Saxon 8.0 which so far only does run-time validation against the
schema, it
>doesn't yet do any compile-time checking (that's next on my list).

Kewl!

>The
>difference basically is that instead of producing incorrect output,
which
>then fails validation at the next stage in the pipeline (the FO
processor in
>this case), you get an error message pointing to the XSLT instruction
that
>produces the invalid output, which gives you a much faster cycle to
correct
>the error.

Yes ... may I suggest (and you've probably thought of this) to make it
fully switchable?  That way during development I incur the processing
time
to make sure everything works as I'm writing my stylesheet, but then
when
I'm confident that my stylesheet is working turn it off ... when
something
is (thought to be) working, I'd like to just use the XSL-FO processor as
a
safety net and pass through my transformation quickly without schema
validation to get results quickly with the (hopefully warranted)
confidence
there isn't a problem lurking in my stylesheet that was not caught
during
testing.

>A shameless plug for my product, I know, but I really have found that
it
>makes a difference.

Not at all, Michael .. worthy of discussion ... I'm looking forward to
seeing how new tools change my day-to-day XSL-FO development for my
customers.

>Following this enquiry, I will now be looking out for an
>opportunity to try it out on a stylesheet that produces XSL-FO output.

But won't you need an XSL-FO schema, then?  I'm not sure one exists ...
unless, perhaps, one took the RenderX DTD to Trang and then tweaked the
result..

Thanks for bringing this up, Michael.

.................... Ken

--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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

Buy Stylus Studio Now

Download The World's Best XML IDE!

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

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