[xep-support] can the < > symbols be replaced with &lt; and &gt;

[Jerry Janofsky]

Ken,

No, you are wrong, you said exactly what I wanted to hear, that is, after I
got passed the momentary feeling of being insulted. 

I think you gave me the solution by saying, " did you consider 
the cell-based row-grouping strategy instead of the row-based 
row-grouping strategy and just use the starts-row= and ends-row=". I didn't
know that existed and believe it might be the answer to my problem.

Also, I did think quite hard about fixing my problem and always try to have
well constructed algorithms. My solution led me to an odd situation,
however, where I was forced to use a CDATA on a <fo:table-row> and
</fo:table-row> because my XSLT document was not valid XML if I didn't use
it.  It just seemed feasible to me that a processor, whether or not it is an
HTML or XSL-FO processor, would understand that &lt; is '<'. From your
reaction, I guess there is something I am terribly confused about.

However, thank you for responding so quickly. I am going to try the cell
based solution. I think it is going to solve my problem.

Jerry J


-----Original Message-----
From: owner-xep-support at renderx.com [mailto:owner-xep-support at renderx.com]
On Behalf Of G. Ken Holman
Sent: Sunday, October 14, 2007 5:04 PM
To: xep-support at renderx.com
Subject: Re: [xep-support] can the < > symbols be replaced with &lt; and
&gt; 

At 2007-10-14 15:39 -0400, Jerry Janofsky wrote:
>I have an issue where I am generating XSL:FO that looks like this 
>(see below) because my XSLT disables output escaping. This 
>understandably causes trouble with XEP 4.6, it ignores the line.

As it should.

>I could avoid this problem if XEP could understand 
>this:  &lt;/fo:table-row&gt; instead of </fo:table-row>   Does it?

It doesn't and it shouldn't.  Why would the text string 
&lt;/fo:table-row&gt; be considered markup?  The whole reason we have 
markup is to avoid such things.

>   <?javax.xml.transform.disable-output-escaping ?>
>   </fo:table-row>
>   <?javax.xml.transform.enable-output-escaping ?>

The fact that you are doing this on the end of a table row indicates 
to me that the original transform could probably be written in such a 
way as to avoid the need for escaping in the first place.  When one 
starts "tricks" to get around a poorly-written algorithm, problems 
are bound to creep up in the long run.  As now.

The *sole* use-case for disable-output-escaping is for sending markup 
such as HTML that cannot be expressed in XML except as a text string 
to a remote system that needs to understand the non-XML as markup not 
as text.  It is not designed for use in hand-crafting pseudo-markup 
to make a transform "easy".

And, anyway ... you are dealing with table rows ... did you consider 
the cell-based row-grouping strategy instead of the row-based 
row-grouping strategy and just use the starts-row= and ends-row= 
attributes to signal the start or the end of a row?

I've come into broken projects as the "fix-it" guy only to find such 
abominations as "&lt;/fo:table-row>&lt;fo:table-row>" because the 
original stylesheet writer didn't take the time to either code the 
algorithm correctly (which takes some thinking; the writer was taking 
a "programming approach" instead of a "templating approach" to the 
problem) or use the alternative approach available in XSL-FO of using 
cell-based properties.

I recommend you study the use of XSLT and XSL-FO and fix your 
original transform such that d-o-e is never used, and then you won't 
have any such problems.

I tell my students "if you think you need disable-output-escaping, 
then think again because you probably don't and you definitely shouldn't".

I hope this helps (though I doubt it is what you wanted to hear).

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


--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman at CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/f/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/f/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service
http://www.renderx.com/terms-of-service.html

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo at renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html