Re: XSL and entities

["John C. Spinosa, MD, PhD" <john@xxxxxxxxxxx>]

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