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

Re: XSL and entities

Subject: Re: XSL and entities
From: "John C. Spinosa, MD, PhD" <john@xxxxxxxxxxx>
Date: Sun, 20 Sep 1998 16:20:48 -0700
c. spinosa
Ken,

Sorry to bother you. If I wanted to learn DSSSL and/or XSL, what could I
read for someone without a CS background? Also, what do you think of Python?

Thanks

John

At 02:31 PM 9/19/98 -0700, you wrote:
>At 98/09/19 16:04 -0400, Elliotte Rusty Harold wrote:
>>At 10:40 AM -0500 9/19/98, Paul Prescod wrote:
>>are you using? This does not look right.
>>>
>>>Nevertheless, you should know that you are probably doomed to failure
>>>using XSL out-of-the-box as a generic XML->foo conversion tool. That's not
>>>what it is meant to do and XSL processors do not support it well. Half of
>>>the messages in this fora are from people trying to do that and finding it
>>>difficult or impossible.
>>>
>>
>>Which begs the question: should there be some other technology which does
>>allow fairly arbitrary conversions from XML->foo? 
>
>Paul said "out-of-the-box" ... he didn't restrict a solution to not using
>XSL at all.
>
>>Something easier than
>>writing a Java program on top of SAX?  What would such a thing look like?
>
>If you are willing to express the "concepts" (dare I say semantics?) of foo
>in XML, say FooML, and then write a translator from FooML to foo, you would
>be able to then use XSL to do your arbitrary conversions from XML->foo as
>follows:
>
>  XML ---XSL--> FooML ---FooXlate--> foo
>
>This does, however, require the FooXlate program to be written, say on top
>of SAX, but written *only once* for all the semantics of whatever makes
>sense for Foo and *without regard* for the transformations necessary from
>other markup languages.
>
>>I have a suspicion the pattern matching might look a lot like XSL, but the
>>output flow objects would be very different.
>
>The transformation would then, in fact, be XSL.  There wouldn't be any
>changes to FooXlate for all of your different XSL transformations for
>arbitrary XML inputs.
>
>Consider the parallel already existing in XSL.  When one wishes to print
>from XML, they think:
>
>   XML ---XSL--> print
>
>... but what is really happening is:
>
>   XML ---XSL--> FormattingObjectMarkupLanguage
>
>and
>
>   FormattingObjectMarkupLanguage ---BackEndFormatter---> print
>
>Vendors will have already written BackEndFormatter for your commonly
>supported print technology (say PDF), so you don't have to write that
>(unless you perhaps have a custom print technology).
>
>I hope this helps.
>
>........ Ken
>
>
>--
>G. Ken Holman               mailto:gkholman@xxxxxxxxxxxxxx
>Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/s/
>Box 266,                                V: +1(613)489-0999
>Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
>Training:   http://www.CraneSoftwrights.com/s/schedule.htm
>Resources: http://www.CraneSoftwrights.com/s/resources.htm
>Shareware: http://www.CraneSoftwrights.com/s/shareware.htm
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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

Buy Stylus Studio Now

Download The World's Best XML IDE!

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

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