- From: <AndrewWatt2001@aol.com>
- Date: Mon, 18 Nov 2002 10:22:00 EST
- To: MSeaborne@origoservices.com
- CC: XForms@yahoogroups.com, www-forms@w3.org
- Message-ID: <7f.2f5fd9c9.2b0a5f98@aol.com>
In a message dated 18/11/2002 14:35:41 GMT Standard Time, MSeaborne@origoservices.com writes: > Well, there is a schema, and I take your point about the value of @id. > However, given that all I'm actually doing is attempting to establish that > one attribute in one part of a XML structure has the same value as another > attribute in another part of a XML structure, I'm not sure that either > point help directly. In fact, I'm not really making use of the fact the two > attributes are of type xsd:id and xsd:idref, am I? > Mark, I guess I should have looked more carefully at your code. I just assumed from reading the title of your email ... :) OK. Let me be honest and first state that my brain is pretty glazed over trying to determine what the XForms WG are really trying to say in the CR. It strikes me as possible that you may be victim of one of the possible Catch 22s that the XForms CR can, **IF** I understand things correctly, produce. As I currently understand things (and the implementor of the tool you are using may have taken a different view) there are two copies of what I will loosely call "instance data". One is "original" and doesn't change and the other is "copy" and can be changed by user interaction. [Corrections welcome.] I think you may be trying to compare back to the original values but am not certain because you didn't provide a full code listing. As I said my brain is pretty much dead at the moment. :) I think the binding expressions may only bind to the copy of the instance data which is in a separate XPath data model from the XPath data model of the "original". If the data has been changed by the user then the original value you expect to compare to won't be there. In other words, if I am understanding the CR correctly (which I may not be), then you can't use a binding expression to access the original values - they bind to the copy. I am pretty clear that you can't access the original values to change them but I think it is possible that you can't access them at all - at least via binding expressions. With repeats and groups it might be even more complicated ... if the XPath node for a repeat which has been added exists in the copy XPath data model and never does exist in the XPath data model for the containing document. But I am not sure if that is what is intended or not. So anyone who wants to create a predicate which needs to access the "original" data may simply be out of luck. It's not too bad if all implementors interpret things the same way but if the implementors take different approaches there could be some *very* puzzling difficulties in writing fairly straightforward code so that it actually works as expected. <shrug/> Just be aware that what I have just written could be total rubbish. :) But it's my best attempt at clarity at the moment while my brain is juggling multiple "If they said XXX then maybe they meant YYY and if that is correct and if it's also correct that when they said AAA they really meant BBB ....". ..... You see the difficulty. :) Andrew Watt
Received on Monday, 18 November 2002 10:22:45 UTC