Re: AI: Precedence order re-wording

Hi Yves,

Yves Savourel wrote:
> Hi Felix, 
> 
> Mmmm...
> 
> Your proposal sounded good to me first. Then I thought what if we have
> several <rules> elements?

good point!

> Then some of the 'xlinked' rules need to be processed before some of the
> embedded rules since we are processing the <rules> in the order we find
> them.
> 
> For example we have:
> 
> <file>
>  <head>
>   <its:rules xlink="xlinkedrules1.xml" ...>
>    <its:translateRule embeddedrule1 .../>
>   </its:rules>
>  <head>
>  ...
>  <footer>
>   <its:rules xlink="xlinkedrules2.xml" ...>
>    <its:translateRule embeddedrule2 .../>
>   </its:rules> </footer>
> <file>
> 
> The precedence order would be:
> Embeddedrule2
> Xlinkedrule2
> Embeddedrule1
> Xlinkedrule1
> Then any external rule associated with tool specific mechanism

Does this have to be the case? The draft is not clear if external, tool
specific rules are related to a complete file or to each separate
<rules> element. Since we don't say anything about the mechanism, both
could be the case.

> 
> So we should really have:
> 
> -----
> 2- Global selections in documents (using a rules element)
> 	Inside each rules element the precedence order is:
> 	a- Any rules inside the rules element
> 	b- Any rules linked via the XLink href attribute
> 3- Global selections in an external file (using a rules element), linked
> via a tool-specific mechanism

Let's call this "version a". If we would have tool-specific external
rules applied to each rule element separately, it would be "version b":

-----
2- Global selections in documents (using a rules element)
	Inside each rules element the precedence order is:
	a- Any rules inside the rules element
	b- Any rules linked via the XLink href attribute
	c- Any rules linked via an external file, using a rules element, linked
via a tool-specific mechanism.
-----



> -----
> 
> Actually this a and b is also valid for #3.

I think we can't say that, it depends whether your tool specific
implementation processes tool-specific linking which is sensitive for
resolution of the XLink attribute. That would be useful, but since we
don't say anything about the mechanism, we can't really require it.

 maybe there is a better way
> to express this?

One solution could be: we make clear in the draft in a note that both
"version a" and "version b" are possible, it's up to you what you do.
And we would leave
"3. Global selections in an external file (using a rules  element),
linked via the XLink href attribute or a different mechanism"
as it is ..., with an intended ambiguity.

Cheers,

Felix

Received on Friday, 12 January 2007 14:10:59 UTC