W3C home > Mailing lists > Public > www-xsl-fo@w3.org > July 2001


From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
Date: Thu, 19 Jul 2001 07:12:35 +0200
To: www-xsl-fo@w3.org
Message-Id: <01071800482600.01509@I1E5U3.accesscable.net>
Hi, all

I could use some feedback. Or I could use some sleep. :-)

In my usual indomitable fashion I am dissecting spec language, with a fine 
disregard for presumable intent, and therefore sticking to the absolute black 
and white. This has usually led me into difficulties. :-)

This time it's about markers. I am trying to make sense of the actual 
language. The discussion pertains heavily to section 6.11.4, 

Let's say that we have a single class of fo:marker, attached as it turns out 
to one area on each page, and all the areas are at the same depth in the 
conceptual area tree. Let's assume that there are no non-normal areas in the 
picture; there is only one normal area per page that has a marker attached, 
all at the same depth in the area tree, and all with the same 
"marker-class-name". So far so good.

On page 'i' we have an fo:retrieve-marker in an fo:static-content. Its 
"retrieve-class-name" matches the "marker-class-name" that the single marker 
on every page has. So by the spec, without applying any other rules (yet), 
every area that has a marker attached is a qualifying area, and the total of 
these qualifying areas is the "hierarchy". Let's say that there are N pages, 
so we have a hierarchy consisting of N areas.

What area is at the "top" of this hierarchy? Note also, that according to the 
spec, the "containing page" is only defined when we have decided what marker 
will be retrieved; the "containing page" also defines everything to do with 
"retrieve-boundary". So at this point, we have no "containing page". That 
means that "retrieve-position" is also meaningless at this juncture.

The spec indicates that a qualifying area in page j+1 is better than a 
qualifying area within page j. This is, in fact, according to a strict 
interpretation of the letter of the spec, the only information that we have. 
Since "retrieve-boundary" and "retrieve-position" are without meaning until 
we define a "containing-page", it seems to me that we will always, according 
to the letter of the law, pick the last page of the document that has a 
qualifying area. _Always_. In a sense we are stll hooped, because the 
properties refer to a "containing page", but that is legally not defined 
until we have nailed down the retrieved marker.

What I am getting at (and I'm being deliberately obtuse to a degree) is that 
there is some missing information, which is leading to circularities. Tell me 
if I'm way off base here, but are not all the properties on 
fo:retrieve-marker intended to help us locate the "best" qualifying area? And 
the marker that is attached to the "best" qualifying area is at the "top" of 
the hierarchy by definition? "Top" just means "best". 
And that the "containing page" is defined by the retrieved fo:marker? This is 
all the precise language of the spec, incidentally.

So how can we possibly specify a "containing page", when the whole purpose of 
the exercise is to select the "best" area that then, ***and only then***, 
lets us determine the "containing page"? I see some problems with this.

OK, I beat this thing to death. :-) But I hope you see my point. I'm not an 
idiot, and I can see exactly what is intended (by common-sense) through the 
various properties. One thing I do know is that the concept of "containing 
page" is awry at the moment. There is clearly also an implicit concept 
(common-sense if nothing else) that the _current_ page (that is, in the 
example we are on page 'i'; the fo:retrieve-marker that we are processing is 
on page 'i' , in other words) is important; the language of the spec accords 
absolutely no importance to that concept. That we are currently on page 'i' 
means nothing, according to the letter of the spec. This is where I think the 
gap occurs.

Now I'm going to sleep. Hopefully I will awake to enlightenment.

Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML
Received on Thursday, 19 July 2001 01:12:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:25 UTC