Created: Tue Feb 07 15:36:27 EST 2006; Last modified: 2006 February 8
Item 1: Explanation that no change will be made
Response from commentor. [None yet]
Item 1: Future XSL version
Response from commentor. Accepts
Item 1: Future XSL version
Response from commentor. [No reply to WG response sent on 26 January 2006]
Item 1: Future XSL version
Response from commentor. [No reply to WG response sent on 26 January 2006]
Item 1: Accepted (clarification)
Response from commentor. Accepts
Item 1: Accepted
(editorial)
Item 2: Accepted (editorial)
Item 3: Future XSL version
Item 4: Accepted (editorial)
Item 5: Accepted
(editorial)
Item 6: Explanation of why no
change will be made
Item 7: Explanation
of why no change will be made
Item 8: Accepted
(editorial)
Item 9: Unclear comment
Item 10: Accepted (editorial)
Item 11: Explanation of why no change will be made
Item 12: Accepted (new functionality)
Item 13: Accepted (bug in spec)
Item 14:
Explanation of why no change will be made
Item 15: Accepted (editorial)
Item 16:
Explanation of why no change will be made
Item 17: Explanation of why no change will be made
Item 18: Accepted (editorial)
Item 19:
Accepted (editorial)
Response from commentor. Accepts
Item 1: Accepted (bug in spec)
Response from commentor. Accepts
Item 1: Accepted (bug in spec)
Response from commentor. Accepts
Item 1: Explanation of XSL spec
Response from commentor. Accepts
Item 1: Explanation
of why no change will be made
Item 2: Accepted
(clarification)
Response from commentor. Accepts
Item 1: Accepted (bug in spec)
Item 2: Accepted
(bug in spec)
Item 3: Explanation of why
no change will be made
Item 4: Explanation
of XSL spec
Item 5: Accepted (editorial)
Response from commentor. Accepts
Item 1: Explanation of XSL spec
Response from commentor. Accepts
Item 1: Accepted (editorial)
Item 2: Explanation
of why no change will be made
Response from commentor. Accepts
Item 1: Explanation of why no change will be made
Response from commentor. Accepts
Peter B. West wrote: > Sharon, > > My apologies for taking so long to respond. > > I did appreciate that the use of the function did not violate lexical > (is that an appropriate term?) inheritance. My concern was with the > mooted changes to "6.4.5 fo:page-sequence", under "Trait Derivation". > > 'The reference-orientation and writing-mode of the > region-viewport-areas are determined by the values of the > "reference-orientation" and "writing-mode" properties of the > fo:page-sequence.' > > Is this change still in play? Sharon,
The answer, as the Last Call makes clear, is "yes". What a astonishing performance by the editors. This change purports to be a "clarification." What it clarifies is that in 1.0 (and the initial draft of 1.1), reference-orientation and writing-mode defined on elements of fo:simple-page-master subtrees were completely inaccessible. In neither 1.0 or the first draft of 1.1 do reference-orientation or writing-mode appear as properties applying to fo:page-sequence. They do, however, appear as properties applying to fo:simple-page-master, fo:region-body, fo:region-before, fo:region-after, fo:region-start and fo:region-end. They still do. A basic prop of the Recommendation has been the inheritance of properties down the FO tree: not, as far as I have ever been able to tell, down the "FO tree that holds the content." For instance, see my question http://lists.w3.org/Archives/Public/xsl-editors/2005JanMar/0060.html substantially unanswered in http://lists.w3.org/Archives/Public/xsl-editors/2005AprJun/0014.html which refers me to http://www.w3.org/2001/08/28-XSL-PR-DOC , comment 20, item 3, a response to a message of 10 Jan 2001, which states, "The design approach taken for XSL was to have a simple inheritance model. Making this change would obviously introduce an exception to this model. ... The consensus of the working group was to not introduce this breaking of the inheritance as it is sometimes very useful and in the cases where it is not what the stylesheet author wishes it is very easy to make an explicit specification ..." That, of course, is also the case here. Should an author be unable, for reasons which escape me, to construct sufficient fo:simple-page-masters to cover their requirements, and insist on overriding the reference-orientation and writing-mode on the fo:simple-page-master they just specified for the current fo:page-sequence, there is always the option to create a top-level reference-area to contain the contents of fo:flow and fo:static-content. The simple-page-master subtree has all the tools for specifying orientation and mode on every region, and that is the job of the page masters. However, the editors have chosen discard the simple inheritance principle, but only in the fo:layout-master-set subtree, and only with respect to reference-orientation and writing-mode. My suggestion is to remove most of this "clarification" from the draft, along with from-page-master-region (still defined, incidentally, with an optional argument which it is an error to use, and other infelicities), and to replace that function with the following: <q> object from-page-sequence() The from-page-page-sequence function returns the computed value of the property for which the expression is being evaluated. In XSL 1.1 this function may only be used as the value of the "writing-mode" and "reference-orientation" properties. The computed value of the designated property is taken from fo:page-sequence ancestor of the formatting object on which the function is being applied. It is an error if the formatting object has no fo:page-sequence ancestor. </q> fo:page-sequence will still need its new adornments of "7.21.3 reference-orientation" and "7.29.7 writing-mode" among the set of properties applying.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0008.html
The editors, The changes to reference-orientation, including its involvement in the from-page-master-region() function and its liberation from inheritance mean, I think, that it is worthwhile re-thinking the whole notion of inheritance for reference-orientation. Now that reference-orientation is not inherited, it must either be specifically set on a reference-area returning FO, or assume the default value, 0. In the previous version of the recommendation, reference-orientation did not apply to fo:page-sequence. Now that it is not inherited, it seems redundant to begin to apply it. Authors wishing to apply a particular reference-orientation to the top-level children of fo:static-content and fo:flow have the option to define such children as reference areas, and place a reference-orientation on them directly. Alternatively, they can define a (non-applying) reference-orientation on fo:page-sequence and access it via from-parent() or from-nearest-specified-value(). What they cannot do is 1) specify one reference-orientation on the relevant fo:layout-master-set element, specify a different orientation on the fo:page-sequence, and 2) expect the fo:block children of fo:flow to exhibit the latter orientation, or expect the orientation of the fo:block-container children to default to the latter. One way to look at a reference-orientation value is as an instruction to set a state of the area tree relative to an ancestor area. A reference-orientation of "0", the default, is a no-op. In this dependency on the area tree it has parallels with percentage values for lengths. Given that, why is it necessary to introduce from-page-master-region() to determine a value for reference-orientation? If 1.0 is left alone, the page-level areas, down to and including span-reference-area and normal-reference-area, will assume the reference-orientation value defined on the relevant ancestor on fo:layout-master-set, or "0". What about writing-mode? Unfortunately, although writing-mode presents similar problems as reference-orientation, it doesn't have such nice characteristics. However, a similar approach can be taken. The draft contains the following in '7.29.7 "writing-mode"'. <quote> The writing-mode trait on an area is indirectly derived from the "writing-mode" property on the formatting object that generates the area or the formatting object ancestors of that formatting object. The "writing-mode" property applies only to formatting objects that set up a reference-area. Each value of writing-mode sets all three of the direction traits indicated in each of the value descriptions above on the reference-area. (See the area model for a description of the direction traits and their usage.) Note: To change the "writing-mode" within an fo:flow or fo:static-content, either the fo:block-container or the fo:inline-container, as appropriate, should be used. </quote> The phrase "formatting object that generates the area" presents all of the usual problems that are associated with fo:page-sequence, of which more later. Leaving that aside, it seems reasonable to specify that, like reference-orientation, writing-mode is not inherited. The difference is that, whereas with reference-orientation, the lack of a specification on a particular reference-area generating fo sends that fo back to the default value of "0", which turns out to be very useful, the Initial value of writing-mode is "lr-tb". What writing-mode needs is a no-op value, which is an instruction to get the value from the current area tree context, without change. Some candidates would be "no-change" and "as-is". On top of the default value, another initial value is required. This would be "lr-tb". Strange as it may seem, this corresponds to the situation with reference-orientation. "0" is "no rotation with respect to the containing reference-area." What is the initial orientation? That depends on the settings of of a number of other properties, for instance media-usage and page-height, and will often devolve to the user agent. Users frequently change from portrait to landscape orientation by specifying page-height and page-width. That results in very different meanings for "0". While reference-orientation can implicitly depend on other properties or the user agent, initial writing mode must, for backward compatibility, be specified as "lr-tb", and this would have to be detailed in the discussion of the writing-mode property. The initial-value, for the purposes of defaulting, would then be specified as "as-is". With that change, the elements of the discussion of reference-orientation would also apply to writing-mode; in particular the manner of specifying a writing-mode on the children of fo:flow and fo:static-content that differs from the writing-mode in effect on the relevant region. fo:page-sequence, in 1.0, embodies a contradiction. On the one hand, it is tasked with "generating" not only the page-viewports, but the region-reference-areas. On the other, reference-orientation and writing-mode do not apply to fo:page-sequence. The editors are seeking to resolve this by applying those properties to fo:page-sequence. However, the properties still apply to the simple-page-master and the region FOs. They must, because, in spite of the language of the draft, those FOs do, in fact, generate reference-areas. Language engineering doesn't alter that reality. My suggestions would require a clarification to the language of area generation. fo:page-sequence would return page-viewport-areas, but not generate them. Likewise, it would not generate region-reference-areas. It does invoke the generation of those areas, because fo:simple-page-master and offspring do not, in isolation, generate anything. They must be invoked by an fo:page-sequence. Once invoked, however, they most definitely generate the reference-areas. This should be made clear in the language of the Recommendation. I realize that this is a critical point. The draft relies on the assertion that fo:page-sequence "generates" page-viewports and region-reference-areas for much of the rationale of what are, to me, controversial changes to the specifying of reference-orientation and writing-mode. My contention is that such changes run against the grain of the underlying structural reality of the use of these properties, and of the inheritance system as a whole. My apologies for the scattered nature of these comments. Thanks for your attention. It is a privilege to be able to participate in such discussions. Peter West -- Peter B. West <http://cv.pbw.id.au/> Folio <http://defoe.sourceforge.net/folio/> --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0009.html
Peter, Pardon me for commenting on your note to the editors, I just have something I'd like to add to a small subset of your remarks: --- "Peter B. West" <lists@pbw.id.au> wrote: > fo:page-sequence, in 1.0, embodies a contradiction. > On the one hand, it > is tasked with "generating" not only the > page-viewports, but the > region-reference-areas. On the other, > reference-orientation and > writing-mode do not apply to fo:page-sequence. The > editors are seeking > to resolve this by applying those properties to > fo:page-sequence. > However, the properties still apply to the > simple-page-master and the > region FOs. They must, because, in spite of the > language of the draft, > those FOs do, in fact, generate reference-areas. > Language engineering > doesn't alter that reality. > The 1.0 Rec in Section 6.1 defines three types of formatting objects: "There are three kinds of formatting objects: (1) those that generate areas, (2) those that return areas, but do not generate them, and --->(3) those that are used in the generation of areas.<--- The first and second kinds are typically called flow objects. The third kind is either a layout object or an auxiliary object. The kind of formatting object is indicated by the terminology used with the object. Formatting objects of the first kind are said to "generate one or more areas". Formatting objects of the second kind are said to "return one or more areas". Formatting objects of the first kind may both generate and return areas. --->Formatting objects of the third kind are "used in the generation of areas"; that is, they act like parameters to the generation process."<--- Wouldn't you say that the fo:region-xxxx FO's and fo:simple-page-master actually fall into the third type (*not* the first), those that are used in the generation of areas, i.e., serve as parameters to the generation process but do not generate areas themselves? > My suggestions would require a clarification to the > language of area > generation. fo:page-sequence would return > page-viewport-areas, but not > generate them. Likewise, it would not generate > region-reference-areas. > It does invoke the generation of those areas, > because > fo:simple-page-master and offspring do not, in > isolation, generate > anything. They must be invoked by an > fo:page-sequence. Once invoked, > however, they most definitely generate the > reference-areas. As above, I see them mainly as auxiliary objects being *used* in the generation process (for obtaining parameters) but not generating areas themselves. But, again, though, I'm commenting just on this small portion of your remarks and not the many others that you had made. Regards, Glen ___________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Disposition: Explanation that no change will be made
NOTE: The SG has spent a lot of time discussing the issues raised here in great detail, and we are convinced that the specification is correct and reasonable as it stands. However, we understand that a careful explanation is in order, and those tasked with generating that explanation have other commitments and have not yet been able to complete that task. We still plan to provide a fuller explanation during the CR period. We apologize for the delay in our response here.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0023
Dear Editors,
It is not uncommon to have text synchronized across a document, i.e. to make sure text lines on all pages, or all columns of a page, start at a multiple of some fixed value. On a multi-column page, for example, there would be no shift of the text lines between two columns, as if a line runs through all columns interleaved with gaps. The text can be temporarily desynchronized because of other kinds of material such as images and tables. It should, however, always fall back in synchronization, in this use case that is. This can be achieved by setting the "line-stacking-strategy" to "line-height" and by calculating "space-before" and "space-after" in such a way that the result after space resolution is always a multiple of the line height. If the font size varies, for example for titles, the combination of the text, "space-before" and "space-after" should be a multiple of the line height. There is, however, a problem with the material that may come between paragraphs, especially when its exact height is not known. In that case the desynchronization can't be compensated with the "space-before" and "space-after" properties. One solution is to add a new value to the "block-progression-dimension" property, for example "round-to-line-height". This would behave as "auto", except that the result is rounded up to the nearest multiple of the line height if the "line-stacking-strategy" is set to "line-height". Another is to add a new value to the "line-stacking-strategy" property, for example "synchronized". The behaviour would be the same as for "line-height", except that text lines would always start at the nearest multiple of the line height starting from the top edge of the content rectangle of the "page-reference-area" (in lrtb writing mode), after space resolution. This would make it much easier for style sheet writers than the first solution.
Disposition: Future XSL version
The XSL FO SG has consensus that this is out of scope for XSL 1.1 whose requirements document is available at http://www.w3.org/TR/xsl11-req/
We will add this feature to our Post-XSL 1.1 Potential Requirements.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2005JulSep/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0017.html
Best regards, Werner. -- Werner Donn頠-- Re BVBA Engelbeekstraat 8 B-3300 Tienen tel: (+32) 486 425803 e-mail: werner.donne@re.be
Hello XSL Editors,
The XSL FO Specifications 1.0 and 1.1 do not specify an order regions are placed on a page. The order of regions is quite important when regions are overlapping or some object is placed out of a region. Currently, an ordering of regions is only supported with Antenna House XSL Formatter in the following way: An order of regions on a page is specified in a simple-page-master by the order of description of region. For example, let simple-page-master specify 3 regions: <fo:region-before ...> ... </fo:region-before> <fo:region-body ...> ... </fo:region-body> <fo:region-after ...> ... </fo:region-after> Then the region-before is placed on a page, then the region-body is placed, and after that the region-after is placed. This order allow put watermarks in a header. I think this very convinient and useful in many cases. For this example, Apache FOP ignores an order of regions and always places regions in the order they should be specified, i.e. region-body, region-before, region-after, etc. RenderX XEP produces a warning that region order is incorrect and works as FOP. The proposal is the following: The order of regions in a simple-page-master can be any. This order specifies an order regions are places on a page produced with this master. I think this proposal is easy for emplementation and it can be included into XSL FO 1.1.
Disposition: Future XSL version
Unfortunately, while the XSL FO SG realizes that it would be useful to be able provide a z-order to the various regions, the SG has decided that this must be considered outside the scope of the (already much delayed) XSL 1.1 spec.
We have put the issue of providing z-order to regions on our list of post-1.1 considerations. In fact, the plan is for a future XSL version to have a more complex page master FO that should address these and other issues.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0001
Sincerely, Alexander I Rozhenko
Hello Editiors,
This is another proposal that allows automatically adjust a body region if static-content regions overlap it. This issue is concerned with adjustment aka MS Word. In MS Word, the extent of headers and footers is not specified. When a header/footer goes over the text area, the top/bottom margin of the text area is adjusted to avoid overlapping. Many users of RTF2FO want a similar behavior for FO renderers. I thing this behavior can be specified as follows: 1 Allow extent="auto" in description of static regions in the simple-page-master. This value means the extent of the region to be calculated when a static-content of the region is prepared. More precisely, the block-progression direction in such region should be parallel with the extent direction. When auto-extent is calculated, only the areas of the xsl-normal class are taken into account. 2 In region-body, additional properties are required. One property is neccessary to allow or disallow adjustment of region margins if auto-extending regions overlap it. Other properties should specify the minimal distance between auto-extending regions and the region-body. This is how I see it: "region-adjust" Value: none | auto Initial: none Inherited: no Percentages: allows adjust "region-body" margins to avoid overlapping with auto-extending regions. Media: visual "region-distance-before" Value: <width> | inherit Initial: 0pt Inherited: no Percentages: Specifies a minimal distance between region-body and auto-extending region-before Media: visual "region-distance-after" .... "region-distance-start" .... "region-distance-end" .... "region-distance" This is a shorthand for all four distances How should they work? If "region-adjust" has the "auto" value, the region-body margins can be adjusted. The decision to adjust a margin is made in the following case: if static content of a neighbor region is auto-extendable, has a positive extent, and the distance between it and the region-body area is less than it is specified in the corresponding "region-distance-..." property. Then the corresponding margin is adjusted to provide the required region-distance.
Disposition: Future XSL version
The XSL FO SG notes that this enhancement request is outside the scope of the XSL 1.1 spec.
The plan is for a future XSL version to have a more complex page master FO that should address these and other issues.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0003
Sincerely, Alexander I Rozhenko
Editors,
The fo:flow-map description appears ambiguous over whether the source flow is to be duplicated (repeated) into each target within the fo:flow-target-list, or is to flow from one target to the next target sequentially, in the order that the targets are defined in the fo:flow-target-list. Both have their use cases--in the case of duplication, for example, to have the same text printed in opposing side regions; or in the case of flowing from one fo:region-body to the next, of having more power in creating a newspaper-style layout. >From http://www.w3.org/TR/xsl11/#fo_flow-map: "For each fo:flow-assignment child of the fo:flow-map, having an fo:flow-source-list child S and an fo:flow-target-list child T, we say that the fo:flow-map assigns -->each<-- of the flows referenced by the fo:flow-name-specifier children of S to the regions referenced by the fo:region-name-specifier children of T." "Each" here, to me, implies duplication/repetition instead of flowing from one target to the next. I'm unsure if that was the SG's intent, however. In the same section a similar ambiguity occurs. While the WD explicitly says *sources* are combined below, the WD is somewhat vague on whether the *targets* are combined or just have the source duplicated in the multiple regions: "The source list is a sequence of flow names whose corresponding fo:flow objects (in the referring fo:page-sequence) are treated as a single fo:flow for composition purposes. The target list is a sequence of region-names which identify the region or regions on each page which are used for the source content." I would recommend the text somehow be made clearer indicating the layout intent for fo:flow-map.
Disposition: Accepted (clarification)
We have added several examples of typical uses of flow maps that should make it easier to read and understand the specification.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0011.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0019.html
Thanks, Glen __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Dear XSL Working Group, With this mail I'm sending you comments about xsl 1.1, which I produced as part of my work in the i18n core wg. I created these comments on my own and distributed them in our group, but the i18n core wg did not have time to discuss them on a telefon conference. So please regard these comments as my private comments, without explicit disagreement from the other working group members. I hope that these comments will be helpful for the further development of your document, which is already an excellent piece of work. And I'm looking forward to your feedback Best regards, Felix Sasaki (team contact of the i18n core wg) P.S.: Currently the comments are just in this mail, but later I will integrate them into the review history page of the i18n core wg, cf. http://www.w3.org/International/reviews/ ------------------------------------------- URI of the spec: http://www.w3.org/TR/2005/WD-xsl11-20050728/
[1] http://www.w3.org/TR/2005/WD-xsl11-20050728/#xml:lang "A language and/or country specifier in conformance with [RFC3066]": Please refer also to the successor of RFC 3066, i.e. please write "A language and/or country specifier in conformance with [RFC3066] or its successor".
Disposition: Accepted (editorial)
The text has been updated in accordance with current XML Recommendation (which has the authorative definition of xml:lang).
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[2] sec. 2.2: Do you support names in the sense of xml 1.1, i.e. http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-Name ?
Disposition: Accepted (editorial)
XSL 1.1 incorporates normatively XSLT 1.0. An erratum to XSLT 1.0 explans the use of XML/XML Names 1.0 and 1.1. A paraphrase of that explanation has been added to section 2.1 and the references to XML/XML Names have been updated to refer to both 1.0 and 1.1 versions.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[3] General: Have you thought about formatting of ruby, cf. http://www.w3.org/TR/ruby/ ?
Disposition: Future XSL version
This request for new functionality will be considered for a future (post 1.1) version of XSL.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[4] editorial: It would be good to have links to the various sections in the indirectly-derived traits overview (end of sec. 4.1)
Disposition: Accepted (editorial)
Note that traits are not properties, but insofar as there are obvious places to link to for some traits, the editor will make an attempt to add them.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[5] editorial: the links to targets in this list (e.g. http://www.w3.org/TR/2005/WD-xsl11-20050728/#linebuilding-6) don't work.
Disposition: Accepted (editorial)
The "specprod" stylesheet has been fixed!
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[6] editorial: longdescriptions are encoded in iso-8859-1, e.g. longdesc/InlineExampleMixed.2a.html , whereas the main document is encoded in utf-8.
Disposition: Explanation of why no change will be made
This doesn't seem to be a problem, so we will leave it as is.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[7] 5.4.6 The Language Property: Please refer to RFC3066 or its successor for the construction of language codes.
Disposition: Explanation of why no change will be made
The language property is a two or three letter code and is not the same as xml:lang. In 7.10.2, we explicitly exclude several of the language codes that 3066 allows.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[8] editorial: ISO639-3 is in the reference section, but not in the main text.
Disposition: Accepted (editorial)
We don't have ISO639-3 in the reference section.
We do have ISO3166-3 (and -1, -2) in the reference section, and they all correspond to the unqualified ISO3166 used in the spec.
To solve the problem of having links from the spec text to the references, we will write "ISO3166 (ISO3166-1, ISO3166-2, ISO3166-3)" in the two places we currently mention ISO3166, and the ISO3166-*'s will be linked down to the entries in the reference section.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[9] editorial: linebreak of code in examples does not work sometimes, see e.g. the example "This example shows a very simple page layout specification. ".
Disposition: Unclear comment
We see nothing strange - browser bug?
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[10] 5.11 Property Datatypes, the datatypes for name and character: please refer to the productions of xml 1.1 instead of xml 1.0.
Disposition: Accepted (editorial)
XSL 1.1 incorporates normatively XSLT 1.0. An erratum to XSLT 1.0 explans the use of XML/XML Names 1.0 and 1.1. A paraphrase of that explanation has been added to section 2.1 and the references to XML/XML Names have been updated to refer to both 1.0 and 1.1 versions.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[11] 5.11 the datatypes country, language and script: The revision of RFC 3066, http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt solves some problems which arise with the the underlying ISO standards (e.g. reliability of values, matching of values). You might have a look into this.
Disposition: Explanation of why no change will be made
See response to comment [7].
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[12] 5.11 uri-specification: please refer to rfc 3987 (IRI) instead of 2396, and add a normative reference to rfc 3987.
Disposition: Accepted (new functionality)
XSL 1.1 will permit IRIs as arguments to the url "function" copied from CSS2. It is our understanding that the SVG WG is also making the same extension, even though the CSS WG has declined to change their definition.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[13] In 7.10.1 "country": you refer to RFC3066; in other sections, you refer to the ISO country codes. Please be more coherent. We would propose a solution like in the comment [11].
Disposition: Accepted (bug in spec)
The definition of "country" in 5.11 is the correct one and 7.10.1 has been updated to be consistent with this.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[14] 7.10 "hypenation properties": these properties are also sensitive to RFC3066, so please think about a solution like [11].
Disposition: Explanation of why no change will be made
The resolution of this comment was achieved at a telcon with representatives from the I18N WG present.
It does seem like this is an incompatible change to XSL.
Felix would understand if we don't want to make such an incompatible change.
SteveZ asks what the advantage would really be to refer to 3066bis here.
CONSENSUS to decline to make any changes based on this comment (though changes based on the previous comment may affect section 7.10).
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[15] Reference to Unicode: Please change the reference to the Unicode standard as described in http://www.w3.org/TR/charmod/#sec-RefUnicode , e.g. Unicode The Unicode Consortium, The Unicode Standard, Version 4.1.0, ISBN 0-321-18578-1, as updated from time to time by the publication of new versions. (See http://www.unicode.org/unicode/standard/versions for the latest version and additional information on versions of the standard and of the Unicode Character Database).
Disposition: Accepted (editorial)
The normative reference to Unicode is not needed in XSL so it has been removed thus addressing the comment.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[16] 7.26: why don't you refer to the definitions of xslt 2.0 for number to string conversions?
Disposition: Explanation of why no change will be made
XSL incorporates the provisions of XSLT 1.0 and thus this is the version of specific items we refer to. For WAI - see e.g. last paragraph of 1.1.1 - and other reasons we cannot mandate the use of a separate XSLT transformation step. We feel it would be too burdensome to require implementation of XSLT 2.0 for vendors that wish to support the, relatively limited, additional functionality of XSL 1.1 compared to 1.0.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[17] 7.26 and in other parts of the spec: "In the XML markup of the figure above, the characters are represented by their presentation form (and not their Unicode code points). The order in which the characters are depicted is their storage order. " You might introduce the terminology "logical order" (which you named storage order) and "visual display", see also http://www.w3.org/TR/charmod/#sec-LogicalOrder
Disposition: Explanation of why no change will be made
The XSL WG finds the term "storage order" to be much less ambigous.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[18] 7.29.7: "This version of the writing-mode property covers the base writing-modes that are used as the official languages of the United Nations." Should this be "This version of the writing-mode property covers the base writing-modes that are used *for* the official languages of the United Nations."?
Disposition: Accepted (editorial)
Comment accepted, but following a decision to move the content of A.1 into 7.29.7 the sentence has been removed.
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
[19] 7.30 xml:lang: For this comment, see also comment [11].
Disposition: Accepted (editorial)
See response to [1]; your comment on xml:lang (which is defined by XML 1.0 and XML 1.1).
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Member/w3c-xsl-fo-sg/2005Dec/0022.html
My apologies for this relatively long post. I am struggling to come to terms with some of the fundamentals of line building.
The spec in 4.6.1 defines what a 'properly stacked' inline-area
is. Items 1. and 2. deal with stacking in IPD and item 3 repeated here
deals with stacking in the BPD:
"3. For any inline-area descendant I of P, the distance in the shift-
direction from the dominant baseline of P to the alignment-point of I
equals the offset between the dominant baseline of P and the baseline of
P corresponding to the alignment-baseline trait of I, plus the sum of
the baseline-shifts for I and all of its ancestors which are descendants
of P.
The first summand is computed to compensate for mixed writing systems
with different baseline types, and the other summands involve deliberate
baseline shifts for things like superscripts and subscripts."
In 7.13 there are examples given and they all work with the above
definition.
Now lets take this example:
<fo:block>Some text
<fo:inline font-size=".5em"
dominant-baseline="reset-size"
alignment-baseline="text-before-edge">top
</fo:inline>
</fo:block>
The inline gets a new baseline table scaled to its font-size because of
the dominant-baseline="reset-size" setting. Note that the
dominant-baseline-indentifier has not changed. Its still "alphabetic"
although that baseline does not align any more between the two areas
because of the rescaling of the baseline table. Now lets give the text
"top" a small suffix.
<fo:block>Some text
<fo:inline font-size=".5em"
dominant-baseline="reset-size"
alignment-baseline="text-before-edge">top
<fo:inline font-size=".5em" alignment-baseline="central">
tiny</fo:inline>
</fo:inline>
</fo:block>
So "tiny" becomes some small text aligned on the central baseline as
established after rescaling. The problem is that the positioning of
"tiny" violates the rule 3. above on proper stacking with respect to the
line-area created by the fo:block. It is OK with respect to its direct
ancestor but it fails when applied recursively. This is because rule 3.
doesn't cater at all for rescaling of the baseline table, it only deals
with changing the alignment point (In my example its first moved to
"text-before-edge" and then to "central") and baseline-shifts. But I
couldn't find anywhere in the spec a notion that baseline rescaling
involves a baseline shift. The problem of course is that when a baseline
table is rescaled there is no uniform shift and the shift amount per
baseline also depends on the alignment.
May be rule 3 is not meant to be applied recursively but than it its
formulated inconsistently with the rest of the spec.Disposition: Accepted (bug in spec)
You correct that there is a problem in the draft.
The text as written now works only in the case where the font sizes are all the same, and in that case the ancestor/descendant constraints are superfluous.
To correct the draft, we will change the first paragraph of item 3 to read:
For any inline-area descendant I of P, the distance in the shift-direction from the dominant baseline of the parent Q of I, to the alignment-point of I equals the offset between the dominant baseline of Q and the baseline of Q corresponding to the alignment-baseline trait of I, plus the baseline-shift for I.
This removes the superfluous constraints and precisely captures our examples.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0012.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
Still seriously confused Regards Manuel Mall
This comment applies to the current spec as well as the current draft.
Both, the alignment-baseline and aligment-adjust properties refer in their descriptions to the values "top", "bottom", "text-top", and "text-bottom". However, in their actual definitions these values are not included. I assume this is an editorial oversight or am I missing something?
Disposition: Accepted (bug in spec)
These baselines are in fact not used and their descriptions have been removed from these property definitions and introductory text.
Regards Manuel
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0006.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
Dear editors,
the Apache FOP team has recently stumbled over a problem concerning the interpretation of the space properties. We've documented the problem and our interpretation on our Wiki: http://wiki.apache.org/xmlgraphics-fop/XslFoSpecificationUncertainties/SpaceTraits A quick check reveals that there are differences of interpretation among FO implementations. In case our interpretation is correct, I'd like to ask the WG to consider a change in wording for the space properties which eliminates the ambiguity. Instead of: Specifies the minimum, optimum, and maximum values for the space before any areas generated by this formatting object and the conditionality and precedence of this space. I'd write: Specifies the minimum, optimum, and maximum values for the space before each area generated by this formatting object and the conditionality and precedence of this space. Instead of: Specifies the value of the space-specifier for the space before the areas generated by this formatting object. I'd write: Specifies the value of the space-specifier for the space before each area generated by this formatting object. This is for space-before. The wording would need to be changed for the other space properties accordingly.
Disposition: Explanation of XSL spec
The XSL FO SG has discussed this and believes the wording in the spec is correct rather than your proposed rephrasing.
Consider a <p> that gets mapped into an fo:block that, due to the amount of content, generates two areas on two consequtive pages. We do not want the space before the fo:block to occur also on the 2nd page.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0002
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0010.html
Thank you. Jeremias Maerki
Hello Editors, A question just came in on the FOP-User mailing list that appears to raise two issues in the 1.1 WD (text also in 1.0) regarding the wording in "2.2 XSL Namespace" section[1]:
1.) Quote: "An element from the XSL namespace may have any attribute not from the XSL namespace, provided that the expanded-name of the attribute has a non-null namespace URI. The --->presence of such attributes must not change the behavior of XSL elements<--- and functions defined in this document.": The arrowed portion above indicates that implementors may not create extension properties that provide any change to the functionality and/or appearance of the XSL formatting objects (that would otherwise be ignored by another implementation that doesn't understand the extension property). If I am reading this correctly, extension properties may then only have semantic value for extension (i.e., non-XSL) formatting objects. But I'm unsure of the benefit of that rule. There doesn't appear to be much value in allowing an extension attribute to be attached to XSL FO's if they may not alter the processing of that FO's. Also, it is the various implementators' work on extension attributes on already defined XSL FO's that help these extensions to be incorporated as official XSL properties in a future release of the recommendation. Further, these extension attributes could still be ignored with no effect on the standard FO functionality for another implementation that would not understand the extension attribute. I guess my recommendation would be to remove the sentence containing the arrows above.
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0003.html
XSLT 1.0 had a similar sentence for extension attributes, and you might like to look at the way we changed it for 2.0. In effect, it now says that an extension attribute may not change the behavior of the processor to a non-conformant behavior, but it may change it "to the extent that the behavior is implementation-defined or implementation-dependent". So if there's nothing in XSL-FO that says whether the pages in the final document should be stapled together, you can add an extension attribute asking for them to be stapled; but if the spec says that they must not be stapled together, then such an extension would be disallowed. Michael Kay
Discussion message: lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0004.html
Hi, 1.) I would be in favour of allowing extension properties to modify the formatting behaviour, so long as they degrade properly. This means that a processor should be allowed to ignore them and fall back on standard formatting behaviour. 2.) It would be more robust if non-inheritable properties would only be allowed on the formatting objects they are defined on. This could break existing XSL-FO documents of course. Regards, Werner.
Disposition: Explanation of why no change will be made
The current wording is meant to imply that extension properties may only change the behavior of an FO in ways that are beyond what the spec says for a particular FO. Some examples of permitted extensions might be like specifying a hyphenation dictionary or hyphenation exception, specifying a whitespace distribution algorithm, etc.
While the XSL FO SG was somewhat divided on the issue, and we certainly do appreciate the viewpoint you espouse, on the whole we have decided to stick with the more restrictive intension currently in the spec. We feel that allowing for extensions that substantially change the already defined semantics for a given FO will cause too many implementation issues.
We are planning to clarify the spec be including something like:
This means that an extension attribute must not change the processing of any FO in such a way that the constraints specified by XSL on that FO are no longer satisfied.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0004
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0019.html
2.) Quote: "It is an error for an element from the XSL namespace to have attributes with expanded-names that have null namespace URIs (i.e., attributes with unprefixed names) other than attributes -->defined for the element<-- in this document." The arrowed portion appears to contradict the rule that "Every formatting property may be specified on every formatting object." ([2], first sentence of chapter 5.) For example, I can place "starting-state" (null namespace URI) on fo:block, even though this property is not "defined for the element in this document." If I'm correct here, my recommendation would be to remove "for the element" at the very end of the quote above.
Disposition: Accepted (clarification)
The WG agrees and will make this change.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0004
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0019.html
Thanks, Glen [1] http://www.w3.org/TR/xsl11/#xsl-namespace [2] http://www.w3.org/TR/xsl11/#refinement
Dear Editors, I am referring to http://lists.w3.org/Archives/Public/xsl-editors/2003JulSep/0012 and the resultant changes in the 1.1 WD and related issues.
1. Under 7.16.8 white-space-treatment it says in the bottom paragraph: <quote> The "white-space-treatment" property specifies the treatment during the refinement process of character flow objects... </quote> However in the above mentioned post as well as in 4.7.2 of the WD it is made clear that the white-space-treatment property is dealt with during line-building and inline-building. 4.7.2 as well as definitions of the property values also indicate that white-space-treatment is enforced by deleting glyph areas, that is it specifies the treatment of glyph areas not flow objects. I therefore suggest in the interest of clarity to change the sentence to something like: The "white-space-treatment" property specifies the treatment during line-building and inline-building of glyph areas...
Disposition: Accepted (bug in spec)
You are correct. We changed white-space-treatment to be handled during line-building and inline-building and missed changing the wording in this descriptive paragraph.
We will adopt your suggested rewording.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
2. A similar issue of clarity exists with respect to the definition of white-space-collapse. There it says in the last paragraph of 7.16.12: <quote> The overall effect of handling the white-space-treatment and linefeed-treatment properties during refinement and the white-space-collapse property during area tree generation is as follows:... </quote> Again it refers to white-space-treatment as being handled during refinement which is in contradiction to the above mentioned post and sections 4.7.2 and 7.16.8 in the WD. However, there is now the problem that both white-space-treatment and white-space-collapse are handled during area tree generation. This leaves, at least in my mind, unclear which one logically happens first. Given that white-space-treatment is defined as a process which deletes glyph areas and white-space-collapse is defined in terms of sibling fo's it seems to me that white-space-collapse has to happen before white-space-treatment but that seems to contradict the intention expressed in the last paragraph of 7.16.12.
Disposition: Accepted (bug in spec)
Same kind of thing as (1.), we simply missed changing it. It should read:
The overall effect of handling the linefeed-treatment property during refinement and the white-space-collapse and white-space-treatment properties during area tree generation is as follows:
Furthermore, the XSL spec does not define a process order, it only specifies constraints on the result.
In particular:
- some FOs generate glyph-areas, some don't.
- 7.16.12 defines conditions on the FO tree which indicate which fo:character elements do or don't generate a glyph area.
- 4.7.2 part 6 talks about what happens when there are glyph areas and defines conditions which indicates which of those get deleted.
If the result conforms to these constraints, the implementation is doing the right thing regardless of the order in which it chooses to do things.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
3. white-space-treatment is as clearly defined in 4.7.2 applied around line breaks. white-space-collapse however only deals with linefeeds (U+000A) and does not seem to apply around other line breaks. Is that intentional?
Disposition: Explanation of why no change will be made
This was one of the many design tradeoffs made during the development of XSL. While it might have been possible to go either way on this, the SG believes we should leave it as it stands at this time.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
4. In 4.7.2 it says in the last paragraph that glyph area merging should only happen on glyph areas with 'matching' traits. No such constraint is put on white-space-treatment (glyph area deletion) nor white-space-collapse in 7.16.12. Is that intentional, that is white space is deleted based only on the Unicode value of the character property/trait independent of any other properties/traits defined on the fo:character/glyph area object involved? Especially white-space-collapse if not happening adjacent to a linefeed seems to have logically more in common with a merge of multiple spaces into one space than a delete of all but one space.
Disposition: Explanation of XSL spec
This is intentional. For example, it is hard to distinguish a bold space from a non-bold space, so we mean to collapse them regardless. In the case of ligatures, we do not want to merge bold and non-bold characters.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
5. In 7.17.3 "suppress-at-line-break" is says: <quote> This property applies only to fo:character and determines whether the character's representation shall be suppressed when it would occur adjacent to a formatter-generated line break. </quote> I am trying to understand the term "formatter-generated line break". If it means line breaks not forced by the user then it doesn't seem to apply here as 4.7.2 explains the use of the suppress-at-line-break property at any line break. If it means any line break then the term "formatter-generated" is confusing and redundant. In either case it seems it should be removed.
Disposition: Accepted (editorial)
We will remove "formatter-generated" in the next draft.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0013.html
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
Regards Manuel Mall
This is a request for clarification:
In 4.5 is says: "The expanded-rectangle of an inline-area is the rectangle with start-edge and end-edge coincident with those of its allocation-rectangle, and whose before-edge and after-edge are outside those of its allocation-rectangle by a distance equal to either (a.) the half-leading, when the area's allocation-rectangle is specified to be the normal-allocation-rectangle by the description of the generating formatting object..." Interpreting this literally would mean for inline areas returning the normal-allocation-rectangle which have border and/or padding that the before-/afer-edges of the expanded rectangle would 'cut through' the border/padding areas. Was that the intention or is the half-leading to be added to the height of the content rectangle and any borders/padding therefore to be outside of that?
Disposition: Explanation of XSL spec
"...for inline areas returning the normal-allocation-rectangle which have border and/or padding[,] the before-/afer-edges of the expanded rectangle would 'cut through' the border/padding areas."
Yes, that was the intention. The intended effect is that adding a border or background will not alter the line spacing.
"... Was that the intention or is the half-leading to be added to the height of the content rectangle and any borders/padding therefore to be outside of that?"
No, that was not the intent. The half-leading is used in determining the line-spacing, but does not alter the allocation area of the inline object itself.
These 2 decisions allow borders and/or backgrounds to be used as a way to highlight inline text where lines need to line up, such as in parallel columns.
If the line spacing is fairly tight or the border+padding on a given inline object is fairly large, the border and background can intrude into the line-area above or the line-area below the current line-area (hence, yes, the line-area's before/after edge can cut through the child inline's padding and border areas).
Note that the line area has no border or padding, only the inlines within the line can have have padding and borders.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0005
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0020.html
Thank you very much Manuel Mall
Dear Editors,
I believe that I've found a minor mistype in the value description
used for allowed-height-scale/allowed-width-scale properties:
[ any | <percentage;> ]* | inherit
the semicolon after "percentage" shouldn't be there (there is no
basic data type "percentage;").
The same mistype present in the description of "intrinsic-scale-value"
property.Disposition: Accepted (editorial)
Thank you for pointing out the typo; we will fix that.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0008
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0016.html
Note also, that content model mentioned above permits attribute values
like this:
allowed-height-scale="10% any 50% any"
though there is nothing terrible about it, one expects that token
"any" should be permitted only once in the list of attribute value
components.Disposition: Explanation of why no change will be made
The XSL FO SG has decided to leave the content model as is and assume that implementations will do reasonable things with potentially duplicate values - be it "any" or a percentage value.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0008
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0016.html
Best regards, Alexander Peshkov mailto:peshkov@renderx.com RenderX
Dear Editors,
a few months ago I documented my interpretation of the XSL-FO 1.0 specification in terms of start-indent and end-indent inheritance on a Wiki page [1]. This is also the way I've implemented the functionality in Apache FOP (see 0.90 alpha1, not 0.20.5). I've come to realize that Apache FOP is currently the only implementation known to me that doesn't deliberately break the property inheritance rules for start-indent and end-indent properties over reference-area boundaries. The XSL WG's disposition on comment 20, item 4 in [2] clearly states that there's merit to stick to the rules. Obviously, I personally agree with this decision but the situation produces unexpected results for inexperienced FO users. That's certainly the main point why many commercial implementors have chosen to break the inheritance rules in this case although this creates an interoperability issue. Since today XSL-FO is possibly worse concerning interoperability than HTML I'd like to ask the XSL WG to reevaluate this topic and to restate their updated opinion in this matter. I don't mind if the WG changes their opinion.
Disposition: Explanation of why no change will be made
The XSL-FO SG has had many long discussions about how inheritance works in XSL FO over the years. We do realize that there are some consequences of the current inheritance model that makes for some results that may be unexpected for some users. This is somewhat unavoidable in that there are (at least) two ways inheritance could work, and both ways are useful in certain circumstances, and the current spec picked one of those two ways.
However, the spec is not unclear in the matter of inheritance (I think you agree on this). The SG has some indication that the various implementations are, in fact, bringing themselves in line with the spec in this regard.
The best way to improve the spec would be to add the capability of requesting the "other" form of inheritance for indents. However, such an addition to the spec is not within the scope of the XSL 1.1 work.
The SG would urge implementors to implement the spec as written. If it is felt it is important to provide the "other" form of inheritance, it should be done via a namespaced extension property. Preferably, implementors who desire such an extension can agree on its general syntax, and perhaps a future version of XSL can incorporate something like that.
Working groups announcement of decision: http://lists.w3.org/Archives/Public/xsl-editors/2005OctDec/0026
Submitter's acceptance of disposition: http://lists.w3.org/Archives/Public/xsl-editors/2006JanMar/0018.html
Furthermore, in my opinion, it is necessary to find a way to improve interoperability between implementations as a whole. It has become a major nuisance. If all implementors sticked their heads together to create an official test suite, it could help improve the situation a lot and it would certainly help clarifying problem spots in the specification as well as put a certain pressure on implementors to improve interoperability. I'd be willing to invest some effort in this. Are there other parties that would be willing to help? [1] http://wiki.apache.org/xmlgraphics-fop/IndentInheritance [2] http://www.w3.org/2001/08/28-XSL-PR-DOC.html Thank you! Best regards, Jeremias Maerki