Re: XForms CR - A further departure from XPath 1.0?

John,

Your comments have helped to make it clearer to me what the CR is trying to 
say. Thank you for that.

If the CR is improved better to express what you state below then I think it 
would be significantly improved.

Inline comments follow below.

In a message dated 13/11/2002 23:18:52 GMT Standard Time, JBoyer@PureEdge.com 
writes:


> The interpretation of / within XForms expressions that reference instance 
> data is perfectly in keeping with XPath 1.0.  

I am not (yet?) convinced of that but at least these comments help me to be 
clearer about what the WG is attempting to say.

As is clearly stated in our definition of the instance element (Section 
3.3.2), the 
> content of the instance element is treated as *opaque data* that is 
> disconnected from the original containing document.  

This presupposes that "opaque data" has some unique, consistent and universal 
meaning. You are using "opaque data" to mean something different from use of 
the term by, say, PostgreSQL users.

I suggest that the WG add a definition of their usage of "opaque data" in 
3.3.2 or refer to a full definition which could usefully be added to the 
Glossary.


> 
> We form a valid ***separate*** XPath data model over a disconnected 
> ***copy*** of the content of the instance element. 

If you re-look at 3.3.2 I think you will find that in the substantive text 
that nowhere does the word "separate" appear. Clearly, at least in my view, 
that notion should be expressed there to improve clarity.

If, for example, the words "an XPath data model" were changed to "a separate 
XPath data model" or "a copy XPath data model" it would be clearer. I think 
that more needs to be said to achieve clarity but that simple change would 
aid communication.

I assume that this is so painfully "obvious" to the WG. Readers, however, are 
not psychic.

 I do not think you will find any spec (much less XPath) that says one is not 

> allowed to take some content from an XML element and put it out to disk then 
> read the separated data with an XML processor.  In XForms, we are careful 
> to say that the instance element can only have one element child so that 
> the ***disconnected copy*** of the content is a well-formed XML document 
> whose resultant XPath data model has a root node wrapped around the root 
> element.  It is this root node that the / operates from.

OK. This much better expresses what I think you intended than the CR seems to 
do. Maybe look at taking some of this text and adding it in appropriate 
places to the CR?

> 
> Although I am taking great pains to explain this,

Thank you for that.

 I do not understand why this is so hard to understand given that this is 
exactly 
> what XSLT does.

With respect, it isn't "exactly" what XSLT does. XSLT starts with two 
separate documents. However, I accept that there are close similarities.

  In XSLT you have numerous XPath expressions that are not references to the 
> document that contains them but rather they are references to the XPath data 
> model of a ***separate*** XML document (the one being transformed by the 
> XSLT that contains the XPath expressions).

No problem with that.

> 
> P.S. Since I agree with Sebastian that Tim Bray likely not listening to 
> this thread, I have removed him from the cc list.  Since this is a public 
> email, however, you can freely forward it as necessary.

We are making progress.

I know it is difficult for WG members to appreciate that readers of a CR have 
only the words of the CR to base their comments on.

You guys know what you mean to say. We on the outside can only attempt to 
arrive at your meaning by reading the words you guys write. If you don't 
write clearly enough we get misunderstandings.

I have separately asked for clarification about what does or does not 
constitute "instance data" and "instance data nodes". An equally clear answer 
to that would let me make further progress in understanding what the WG is 
attempting to communicate.

Andrew Watt

Received on Thursday, 14 November 2002 07:00:29 UTC