At 10:03 AM 7/10/01 +0200, Keiron Liddle wrote:
>
>On Mon, 09 Jul 2001 12:47:02 Arved Sandstrom wrote:
>> Not only all of the above, but we need to ensure that areas actually have
>>
>> all the properties they are supposed to have. OK, there is still the
>> question, do you really want to add a property to foproperties.xml just
>> so
>> you can print it out, even if it's essentially unused, and I don't have a
>>
>> good answer to that one, because it could result in confusion. But I am
>> thinking more of things like area-class, generated-by, returned-by,
>> is-reference-area, is-last, is-first...all things on which we are really
>> spotty.
>
>Of course I just added all the properties (String only) to the
>foproperties.xml a moment before. I figured its such a pain to read them
>all it would be better to have them all in there.
>If need be we could comment them out or change the type to NotImplemented
>or something.
I noticed that it popped up on the commit list about 2 or 3 minutes after I
sent my post. Great minds think alike, I guess. Or is that also covered by
"equal minds think alike"? :-)
No harm done, IMO, if everything is actually in there. But that means that
we do need a strategy to indicate status - I prefer one that is integral to
the file so things are self-documenting. You suggested 2 possibilities and I
think either work; the latter is maybe better. We should also maybe think of
comments anyway, as a matter of course, to help note and describe partial
implementations. To date it's been quite a hassle documenting status (one
main reason why STATUS for 0.19 isn't), and that's mostly because things are
not documented in a natural, central way. Maybe we can use the data files
themselves to obviate the need for any other record-keeping.
>> I am probably going to be adding is-first and is-last because I need it
>> in
>> some spots anyway, for fixing a situation that causes errors with
>> break-before="page" and break-after="page".
>>
>> Just as a heads up, I am going to be writing some test validation scripts
>>
>> for pagination test cases. My thought is to use a single XML in
>> conjunction
>> with XSLT to run all of the actual test cases (I prefer to leave the
>> current
>> pagination examples as examples, and not use them in tests), and then to
>> write some simple, efficient Perl and/or Python to process the area tree.
>>
>> Any guidance on how you would like to see stuff organized is welcome.
>
>It sounds like you are talking about some post-processing of the area tree
>output with a particular focus on pages (numbering, layout ...).
In this particular case yes. The information is present.
>My immediate thought is that we could take full advantage of the xml
>structure. For example, using xpath to make selections on the xml and
>verify parts of the data. In this way we could have markers in the xml
>which help with the selection.
Absolutely...I think the XML structure is great and plan to leverage it.
General approach would be to extract using one or more XML
parsing/XPath/XSLT modules in Perl or Python, and then apply test result
logic. One of my main motivations for using Perl or Python here is I can do
the logic much faster and easier...in particular, regular expressions and
list manipulations.
>It would be good if the testsuite.dtd could be followed if it is
>appropriate in this case.
That is my intention. I think the testsuite.dtd is perfectly OK. A suitably
automated test harness would presumably also read and update tests based on
this DTD (DOM, possibly); I don't think I will get that elaborate yet.
Regards,
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
