- From: Arved Sandstrom <Arved_37@chebucto.ns.ca>
- Date: Thu, 19 Jul 2001 07:12:35 +0200
- To: www-xsl-fo@w3.org
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, fo:retrieve-marker. 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. Regards, 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