W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2005

Strong disagreement with limitation of change bar definition

From: Jim Melton <jim.melton@acm.org>
Date: Sat, 19 Feb 2005 19:13:38 -0700
Message-Id: <6.2.0.14.2.20050219182106.031e2c70@rgmstimap.oraclecorp.com>
To: xsl-editors@w3.org
Cc: W3C-XSL-FO-SG@w3.org, jim.melton@acm.org
Gentlepeople,

I noticed with great joy (I'm not kidding!) that the XSL 1.1 draft dated 
2004-12-16 contained a definition of two new elements, <change-bar-begin> 
and <change-bar-end>.  My choice of FO rendering engines, RenderX' XEP has 
an implementation of this part of the XSL 1.1 draft in their version 4.2 
(as RenderX extensions in their own rx: namespace), so I experimented with 
it.  (Yes, I know that this material was in earlier editions, but I paid 
scant attention until I had an implementation with which to experiment.)

I've scoured the W3C archives (public and private lists, since I'm a W3C 
participant) and found exactly 10 messages dealing with 
change-bar-begin/-end.  None of the directly address this deficiency, but 
some of the earlier proposals for change-bar support said that the elements 
would be allowed "virtually anywhere in an FO", but the listed %block;, 
%inline; and CDATA as specifics.

In short, the definition of these two elements falls short of my 
requirements, which I firmly believe to be pretty common, in one particular 
way.  Here are the steps that leads me to my very strong request for a 
modification --- indeed, a fix --- of this feature.

1) The XEP 4.2 Reference manual, in section 3.6.6, says:

XEP 4.2 has support for change regions, as described in XSL 1.1 Working 
Draft of December 16,
2004, http://www.w3.org/TR/2004/WD-xsl11-20041216/.
<rx:change-bar-begin>
<rx:change-bar-end>
These elements have exactly the same meaning and properties as listed in 
the Working Draft
for elements <fo:change-bar-begin> and <fo:change-bar-end>, sections 6.3.12 
and 6.3.13,
respectively.

All well and good, so I know that my rendering engine at least intends to 
follow the spec.

2) The XSL 1.1 spec, in section 6.2, Formatting Object Content, says about 
their corresponding <fo:change-bar-begin> and <fo:change-bar-end> elements:

The following formatting objects are "neutral" containers and may be used, 
provided that the additional constraints listed under each formatting 
object are satisfied, anywhere where #PCDATA, %block;, or %inline; are allowed:

      ...
      change-bar-begin
      change-bar-end
      ...

3) When I place a <change-bar-begin class="a"/> element into my XSL FO 
files, I get validation errors if they are in just any place.  For example, 
in the following XSL FO fragment, I get the following message:

======FO fragment======

<fo:list-block provisional-label-separation="3pt" 
space-before.optimum="6pt" provisional-distance-between-starts="18pt">

<rx:change-bar-begin change-bar-class="a"/>

<fo:list-item space-before.optimum="8pt" relative-align="baseline" 
hyphenate="true"><fo:list-item-label end-indent="label-end()"><fo:block 
text-align="start"></fo:block></fo:list-item-label><fo:list-item-body 
start-indent="body-start()"><fo:block>Manages the SQL-session taking place 
over the SQL-connection betweenand the SQL-client.
</fo:block></fo:list-item-body></fo:list-item>

<rx:change-bar-end change-bar-class="a"/>

</fo:list-block>

======error messages======

[error] Element 'rx:change-bar-begin' cannot be a child of 'fo:list-block'. 
Only 'list-item' or 'marker' elements are permitted in this context.

[error] Element 'rx:change-bar-end' cannot be a child of 'fo:list-block'. 
Only 'list-item' or 'marker' elements are permitted in this context.

============

My first thought was "this indicates that the XEP implementation of 
change-bar-begin/-end does not allow it to appear "anywhere where #PCDATA, 
%block;, or %inline;" can appear."  Sounds like an XEP bug.

However, upon examination of the XSL 1.1 spec, I see that %block; is 
exactly "block, block-container, table-and-caption, table, and list-block" 
and nothing more; note that it does not include fo:list-item elements.

This is a very major problem, hence my comment to the XSL FO committee in 
W3C.

The reason that it's a major problem is very simple: When a large, complex 
document containing hundreds or thousands of lists, many of which have 
dozens or scores of list items, one absolutely does not want to put a 
change bar besides an entire list in which a single list item has had a 
single word changed.  It is certainly most convenient when editing the XML 
sources of such a document to put the change-bar-begin immediately before 
the XML element tag (e.g., <li>) that starts the list item and the 
change-bar-end immediately following the end of that element (e.g., the tag 
</li>).

I would be very interested to learn why this limitation was though to be 
reasonable, but I am highly skeptical that I will be convinced that the 
limitation is acceptable.

Please remember that XSL FO is often (usually?) produced by application of 
an XSLT stylesheet to some XML source.  If that XML source contains a 
fragment such as this:

<list>
<li>This is the first bullet.</li>
<start-change/>
<li>This is the second bullet.</li>
<end-change/>
<li>This is the third bullet.</li>
</list>

then the stylesheet that transforms this to XSL FO will have to generate 
something like this:

<fo:list-block provisional-label-separation="3pt" 
space-before.optimum="6pt" provisional-distance-between-starts="18pt">

   <fo:list-item space-before.optimum="8pt" relative-align="baseline" 
hyphenate="true">
     <fo:list-item-label end-indent="label-end()">
       <fo:block text-align="start">1</fo:block>
     </fo:list-item-label>
     <fo:list-item-body start-indent="body-start()">
       <fo:block>This is the first bullet. </fo:block>
     </fo:list-item-body>
   </fo:list-item>

   <fo:list-item space-before.optimum="8pt" relative-align="baseline" 
hyphenate="true">
     <fo:list-item-label end-indent="label-end()">
<fo:change-bar-begin ...attributes.../>
       <fo:block text-align="start">2</fo:block>
     </fo:list-item-label>
     <fo:list-item-body start-indent="body-start()">
       <fo:block>This is the second bullet. </fo:block>
<fo:change-bar-end ...attributes.../>
     </fo:list-item-body>
   </fo:list-item>

   <fo:list-item space-before.optimum="8pt" relative-align="baseline" 
hyphenate="true">
     <fo:list-item-label end-indent="label-end()">
       <fo:block text-align="start">3</fo:block>
     </fo:list-item-label>
     <fo:list-item-body start-indent="body-start()">
       <fo:block>This is the third bullet. </fo:block>
     </fo:list-item-body>
   </fo:list-item>

</fo:list-block>

This essentially would require that the stylesheet be stateful, 
"remembering" that a <li> was preceded by a <start-change> so the 
<fo:change-bar-begin/> can be inserted at a place where %block; elements 
are allowed.  That is highly unnatural, and not a little inconvenient.

Of course, I am willing to be shown that I am wrong and that it would be 
easy to overcome the limitation.

I look forward to your comments.

Many thanks,
    Jim

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Co-Chair, W3C XML Query WG; F&O (etc.) editor    Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
========================================================================
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
======================================================================== 
Received on Sunday, 20 February 2005 02:19:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:58 GMT