An extension can be a javascript function embedded in some part of the
stylesheet[or an imported ancillary stylesheet] which the client can
control.

http://xml.apache.org/xalan-j/extensions.html#ex-basic

-----Original Message-----
From: Jim Urban [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 04, 2001 6:06 PM
To: [EMAIL PROTECTED]
Subject: RE: Page Breaks


I doubt that would be permissible since the client wouldn't be able to
control the extension (I'm assuming an extension is a compiled class).

Jim

-----Original Message-----
From: Alistair Hopkins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 04, 2001 11:17 AM
To: [EMAIL PROTECTED]
Subject: RE: Page Breaks


How about an extension to XSL / Xalan?  Would that be permissible, or
possible?

<xsl:value-of select='myExt:mayHaveLineBreak(rawNode,'\n')'/>

Ugly, but keeps control with the client...

-----Original Message-----
From: Jim Urban [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 04, 2001 5:05 PM
To: [EMAIL PROTECTED]
Subject: RE: Page Breaks


I agree with what you are saying.  Here is the rule that I may not have
explicitly stated:
The data in our database comes from several legacy system.  This data can
not be modified by anything that our client does not directly control.  Our
applications are of the highest level of mission critical.  They are used by
physicians to determine how to treat patients and errors in the data we
present can have life or death consequences.

XSLT is under the control of our client.  The client can edit the XSL file.
The client can also request our servlets to return the raw XML for comparing
to the database to insure the data is 100% correct.  Any modifications
(however small) done by our Java code is outside our client's control.  That
is, our client does not have our Java source and can not make changes to it.
It all comes down to our having to meet a vary huge and strict set of
federal laws regarding data integrity and security called HIPPA.

I hope this explains my situation.  Now lets move on.  :)

Jim

-----Original Message-----
From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 04, 2001 10:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Page Breaks


Not to start a war here...let me put it this way. The fact that my initial
suggestion referenced Perl is actually irrelevant. Your servlet can do the
equivalent. After all, at the point where you are presenting XML to the XSLT
processor it is plaintext, right? So we are talking about inserting one
extra transformation step at this point...doesn't even have to use regular
expressions, and of course it can be written in Java. Nothing needs to be
written out to an intermediate file at all.

What I don't understand is an insistence that the only _modification_ and
_transformation_ which can be done with the data is through XSLT. And make
no mistake, XSLT "formatting for display", as you put it, _is_
transformation and modification. How do you figure that XSLT does not allow
you to change the data? The original data isn't what we are talking about in
any case - even my Perl one-liner did a backup.

As far as the comment about not letting developers use whatever technology
they like, hey, that's a given. Every project has a point where the choices
like that are made. Here's what I sense - you guys have a strong commitment
to data integrity and security, and I respect that. But you mistakenly
assume that use of XSLT is somehow going to avoid data integrity problems,
and I dispute that. _Correct_ XSLT code will avoid that problem, just as
_correct_ use of another approach would also (I use the word "code"
advisedly, because XSLT is code; no different from Perl, actually).

Regards,
Arved Sandstrom

----- Original Message -----
From: "Jim Urban" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 04, 2001 11:54 AM
Subject: RE: Page Breaks


> Our application is a web application implemented in Java Servlets.  To use
> the perl approach, we would have to call a perl script from within our
> servlet, passing the data in memory to the script.  The script would then
> have to modify the data and return it in memory to the servlet.  The data
> can NOT be written to a file without encrypting it.
>
> Using XSLT does not change the data.  It simply formats the data for
> display.  This formatting is controlled by the client, not our Java code.
> Our servlet has the ability to send back the raw XML so the client can see
> the "raw" unformatted data for verification purposes, I must maintain this
> option.
>
> > I'll use anything that works.
> > the day I start imposing my language preferences on a solution is the
> > day I should look for other work.
> As a product development manager, I can not let each developer (myself
> included) "use anything that works".  I manage a TEAM of developers.  We
> build and maintain professional software products that are built on a
common
> frame work, language and set of tools.  If you could not conform to our
way
> of doing things I would "ask" you to "look for other work".
>
> Jim
>
> -----Original Message-----
> From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 04, 2001 9:01 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Page Breaks
>
>
> I hear you saying that modification of XML data with XSL is not really
> modification at all, but modification with Perl is bad. Seems somewhat
> unusual.
>
> Sorry you've had problems with scripting languages. I happen to be a
> professional software developer, and despite some current disillusionment
> with Java hype, I'll use anything that works. Past 2 years it was all J2EE
> and XML; I am working on a contract right now that is MS SQL Server, VC++
> and ASPs. I could care less - the day I start imposing my language
> preferences on a solution is the day I should look for other work.
>
> And in fact I did not understand your argument.
>
> Regards,
> AHS
>
> ----- Original Message -----
> From: "Jim Urban" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, December 04, 2001 10:33 AM
> Subject: RE: Page Breaks
>
>
> > Perl?  We are Java Servlet web based application.  We don't even own a
> Perl
> > interpreter (thank God!).  :)
> >
> > We are in the healthcare industry and data integrety is a major issue.
We
> > can not change the content of a client's data from within our code.  The
> > only way to modify the content of our client's data is through XSL which
> is
> > maintained by the client.  So as you see, we do need an XSL / FO
> sollution.
> >
> > Jim
> >
> > -----Original Message-----
> > From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 04, 2001 8:06 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Page Breaks
> >
> >
> > Not everything needs to be XSLT. In this case you could preprocess with
a
> > Perl one-liner that would be blazingly fast. Something like:
> >
> > perl -i.bak -pe 's!\x0C!<ff/>!g;' XMLFILE
> >
> > (Use double quotes on a Windows command-line). Then you'll have <ff/>
> > elements that you can act on in your XSLT.
> >
> > Regards,
> > Arved Sandstrom
> >
> > ----- Original Message -----
> > From: "Jim Urban" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, December 04, 2001 9:25 AM
> > Subject: RE: Page Breaks
> >
> >
> > > I'm using XSLT to translate XML into FO.  The field containing the
form
> > > feeds is a text element.  I need to be able to do this using XSL.
> > >
> > > Jim
> > >
> > > -----Original Message-----
> > > From: Mike Akerman [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, December 03, 2001 4:18 PM
> > > To: FOP Dev
> > > Subject: Re: Page Breaks
> > >
> > >
> > >
> > > On Mon, 3 Dec 2001, Jim Urban wrote:
> > >
> > > > I have a servlet which dynamically generates XML which is then
> > translated
> > > > into FO and ran through FOP to generate PDFs.  What can I embed
(like
> a
> > > > "\f") in the XML text that will cause FOP to automatically start a
new
> > > page?
> > > >
> > > > Thanks,
> > > >
> > > > Jim Urban
> > >
> > > I've translated "\f" into:
> > >
> > > </fo:flow>
> > > </fo:page-sequence>
> > > <fo:page-sequence master-name="simple">
> > > <fo:flow flow-name="xsl-region-body">
> > >
> > > If thats not sufficently clear, I could provide an example plain-text
to
> > > xsl-fo conversion program I've written.
> > >
> > > Michael Akerman
> > >
> > >
> > > -----------------------------------------------------------------
> > >
> > > [EMAIL PROTECTED] Information Services
> > > (501) 575-5870 University of Arkansas
> > > http://www.uark.edu/~mike
> > >
> > > -----------------------------------------------------------------
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to