Two content model concerns for 1.1 WD

Editors,

I had two content model concerns that may have been
miscategorized as editorial in nature.  I have not
seen any correction in the latest WD, and want to make
sure that indeed the new CM's are what is actually
desired for 1.1.

1.) (#62 of my previous comment list)  The CM for
fo:simple-page-master changed from 1.0 to 1.1 to allow
for multiple fo:region-bodies:

1.0 --
(region-body,region-before?,region-after?,region-start?,region-end?)

1.1 --
(region-body+,region-before?,region-after?,region-start?,region-end?)

I'm not seeing what multiple fo:region-bodies for an
fo:s-p-m are providing in 1.1, or why the SG moved to
this for the new model.  Is it related to the new
fo:flow-maps?  I would appreciate "enlightenment" from
anyone here--not necessarily the SG--as I'm quite
curious as to the purpose of multiple fo:region-bodies
in 1.1!

2.) (#74 of my previous comment list)  In accomodating
the new fo:flow-map within the fo:layout-master-set,
it appears that the new CM is inadvertently now making

CM recommendation for fo:static-content and fo:flow

[Happy Independence Day fellow Americans!]

Editors,

One more 1.1 WD CM suggestion (just editorial here)--
the constraints defined within fo:marker and
fo:retrieve-marker prohibit these FO's from being
descendants of fo:static-content and fo:flow,
respectively.  

I think it would be very helpful for the implementor
if these two rules were copied (or moved) to the CM
definitions of the parent fo:flow and
fo:static-content FO's.  I originally missed
implementing enforcement of these rules for fo:flow
and fo:s-c in FOP, because they were missing from
these FO's CM definitions.

For almost all of the formatting objects, the content
model is fully defined in the CM for that formatting
object--i.e., it is not necessary to do a full scan of
the XSL specification in order to determine the actual
CM of a formatting object.  This saves sanity on the
part of the implementor, and also adheres to the idea
normally held by the recommendation that the parent FO
defines its CM, rather than having child FO's
determine their legal parents.  

Regards,

FAQ

Re: from-page-master-region() and Re: reference-orientation

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?

Peter

Sharon Adler wrote:
> Peter,
> 
> Yes you are correct in that we should not violate our rule to have
> inheritance down the  FO tree that holds the content.  We do not believe we
> have properties that inherit from the fo:layout-master-set.  Pulling a
> value using a property-value function is not inheritance.
> 
> Thanks again for your comments and interest in XSL 1.1.
> 
> Sharon
> 
> 
> 
> 
> Sharon Adler wrote:
> 
>>Peter,
>>
>>I must apologize for taking so long to answer your comment on XSL 1.1.
> 
> We
> 
>>value your comments and recognize that we need to introduce an
> 
> inheritance
> 
>>mechanism that inherits selectively from the layout rather than down
>>formatting object tree.  However, we believe that this is part of a more
>>extensive set of functionality we wish to introduce in the next version
> 
> of
> 
>>XSL.  It is at that time that we will design "layout-driven inheritance".
>>
>>Thank you for your interest in XSL 1.1.
>>
>>Sharon
> 
> 
> Sharon,
> 
> Thank you for your response.  I have some feeling for the difficulties
> the editors face with these questions.
> 
> Given that the editors wish to retain a simple FO tree inheritance
> model, it seems to me important that such a principle not be violated
> for the properties on the fo:layout-master-set subtree.  If properties
> on, e.g., individual fo:region-body elements are inherited, not down the
> fo:layout-master-set subtree, but through the fo:page-sequence-master,
> then FO tree inheritance has been partially replaced by layout driven
> inheritance.
> 
> I much appreciate the efforts of the editors.

--

-- 
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
<http://folio.bkbits.net/> <- the atTridged version

Re: Binary output method