W3C home > Mailing lists > Public > www-forms@w3.org > August 2002

Dynamic dependencies

From: Paul Prescod <paul@prescod.net>
Date: Wed, 21 Aug 2002 16:37:49 -0700
Message-ID: <3D64244D.A3059AE@prescod.net>
To: "www-forms@w3.org" <www-forms@w3.org>, www-forms-editor@w3.org

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

> 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 19:40:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:06 UTC