Apologies for the delay, here are results of my investigation what are parameters for existing behaviours. As a general rule, any XPath expression is allowed as parameter value, though sometimes these expressions are just strings like 'bottom' or 'page', quoted to mean literal string in XPath. Thus all parameters have XPath datatype, but of course expected results for expressions that these XPaths evaluate to are different depending on the behaviour/parameter pair. <!-- these are all the different param/@name values which polygon knows about--> <valList type="closed"><!-- or semi? --> <valItem ident='alternate'/> expression pointing at content to process as alternative (eg. for options wrapped in choice); only used for behaviour="alternate" <valItem ident='content'/> expression pointing at content to process in a behaviour (common for all behaviours with the exception of alternate and omit); only parameter so far that *has* default value (being currently processed element) <valItem ident='default'/> same as content but used only for behaviour="alternate" <valItem ident='height'/> should evaluate to something that can be used as a value for @height attribute on html:img; used for behaviour="graphic" <valItem ident='id'/> expression that should evaluate to something that could be used as identifiers for an anchor, so similar to url/link but only for linking within the same document; used only for behaviour="anchor" <valItem ident='label'/> expression that should evaluate to something that could be used as label for breaks (eg. concat('Page ', @n) would produce labels like 'Page 1', 'Page 2' etc; used only for behaviour="break" <valItem ident='level'/> should evaluate to a positive integer, used on behaviour="heading" to specify its level <valItem ident='link'/> expression pointing where to find content to be used as URL for hyperlink generated with behaviour="link" <valItem ident='place'/> expression (quite often just literal string, but XPath expression nevertheless) that should evaluate to a name of the location for the note generated; in current xslt implementation if it evaluates to 'bottom' it gets special treatment, an anchor linking to a div containing the actual note, all others are enclosed in spans (don't ask me why); used only on behaviour="note" <valItem ident='scale'/> present on parameter list for behaviour="graphic" but not used at all <valItem ident='type'/> envisioned to be used to specify the kind of break to perform (when used on behaviour="break") or index to generate (if used on behaviour="index") <valItem ident='url'/> same as link but used for behaviour="graphic" to be used as a value of img/@src when transforming to html <valItem ident='width'/> same as height but, of course, for width </valList> On 9 February 2016 at 22:32, Magdalena Turska <tuurma@gmail.com> wrote:
Thanks Lou, was trying to fight the bug in procmod stylesheet on Sunday, I know what the issue is but my fix broke it in other places. Oh well, I do miss Sebastian a lot. Will bang my head on the wall a little and try again over next couple of days.
On 9 February 2016 at 19:11, Lou Burnard <lou.burnard@retired.ox.ac.uk> wrote:
I've done some minor revision of the TD chapter in the lb42-procmod chapter, addressing (I hope) some of Magdalena's concerns, though probably not all of them. Unfortunately I reformatted the whole chapter with Oxygen, making it hard to see exactly what I've changed, but it wasn't a lot, honest.
I also added a <valList> to the param/@name attribute, and added the proposed model/@cssClass attribute.
I'm still confused about how <param> is supposed to work though. And the procmodtest still doesn't work. Over to you, Magdalena!
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived