RE: Dynamic dependencies

Hi Paul,

The calculation stuff in general has been the subject of many conversations
here, most of them  painfully technical. :-)

The problem is that if a form can shift around dependencies *during* the
recalculate, it is possible to get very long (including infinite) numbers of
steps needed to complete the calculation. This is ultimately a
form-authoring error, but still it's terribly unfriendly to go into a
recalculate and never come out!

>Grammar error around "there".
there <ins>are</ins> restrictions... (thanks)

>many predicates do not have a comparison, e.g. "img[@foo]".
OK, up front, let me say that nothing in this message should be taken to
mean I don't think the text can be improved in any way. It certainly could
be better.

A predicate filters the node-set to which it's attached, and therefore has
the ability to shift around dependencies during a recalculate. I would like
to hear alternate ways to word this.

>Is a dynamic dependency something that can be determined merely from the
form of an XPath, without its form context?

Generally, no. It will depend on other things in the form (which is why it's
so hard to detect in many cases) The case of img[@foo] will depend on what
happens elsewhere that affects @foo.

> Note: Is this note something that I should be able to figure out..

All "Note:"s are non-normative. You should, in principle, be able to figure
out what that note says by reading the rest of the spec.

>> A dynamic dependency does not result if either side of the predicate 
>> is one of the following: position(), last(), count(), or index(); 

>It seems to contradict the rule before because you say that if ONE side
>is position() or count() then you are okay, but above you say BOTH sides
>need to be fixed. I suspect you were correct above.

Let me think about this one a little..

>> both the parameter to the function and the matching attribute of type 
>> xsd:ID are fixed. 

>Do you mean the matching attribute of an element or that the matching
>attribute's declaration must be #FIXED?

Not #FIXED. Just "fixed", as defined in the earlier paragraph. Perhaps
quotes around "fixed" would help.

Thanks,

.micah


-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Wednesday, August 21, 2002 4:38 PM
To: www-forms@w3.org; www-forms-editor@w3.org
Subject: Dynamic dependencies



I'm having a hard time understanding Dynamic Dependencies.

> In particular, there restrictions on binding expressions that create 
> dynamic dependencies, which are defined as follows:

Grammar error around "there".

> Any XPath predicate expression (in square brackets) is a dynamic 
> dependency unless both sides of the comparison are "fixed", where 
> fixed means either a constant, or a value that will not change 
> between operations explicitly defined as rebuilding computational 
> dependencies.

First, many predicates do not have a comparison, e.g. "img[@foo]".

I guess "@foo" is not a constant so the next question is whether it is a
"value that will change between operations explicitly (etc. etc.)". I
just can't understand that part. Perhaps if I read the XForms spec from
start to finish (which I admit I haven't). But I've done lots of work
with XPath and I would have thought that would been background enough.

Is a dynamic dependency something that can be determined merely from the
form of an XPath, without its form context? Or does it matter what
widgets are on the form and how they change the data items.

> Note:

Is this note something that I should be able to figure out based on the
statement before or a new (normative) rule?

> A dynamic dependency does not result if either side of the predicate 
> is one of the following: position(), last(), count(), or index(); 

It seems to contradict the rule before because you say that if ONE side
is position() or count() then you are okay, but above you say BOTH sides
need to be fixed. I suspect you were correct above.

>...
> Another dynamic dependency is any use of the id() function, unless 

It sounds like you've just been listing dynamic dependencies but you
haven't.

> both the parameter to the function and the matching attribute of type 
> xsd:ID are fixed. 

Do you mean the matching attribute of an element or that the matching
attribute's declaration must be #FIXED?

I understand what you are trying to do: keep from too much recalculation
and propagration of values. But this section confused me.
-- 
 Paul Prescod

Received on Wednesday, 21 August 2002 20:52:36 UTC