Re: [xml-dev] Changing XPath 1.0 Semantics in XForms 1.0?

[AndrewWatt2000@aol.com]

Micah,

I hope you don't mind but I have changed the title of the post back to the one I used to start the thread. I at no time suggested that XPath 1.0 was changing the semantics of XForms 1.0 as your modified title would imply.

I think you slightly do your argument a dis-service by not explaining what I now (tentatively) understand to be the XForms WG's intention - that there are *copies* of the "instance data" (a term which needs clearer definition in my view) as *separate* XPath data models.

Further comments in line.

In a message dated 15/11/2002 08:15:49 GMT Standard Time, MDubinko@cardiff.com writes:


> Some of the off-list responses I've gotten have made me question what I once
> thought was a slam-dunk.


I asked the original question on XML-Dev because I wanted other pairs of eyes (attached to sharp intellects) to come at this problem fresh. If any of those who emailed Micah off list would care to post those emails (or the technical issues contained in them) to this list that would help me get clearer perspective on this.

By the way a "slam-dunk" is pretty much a semantics-free term east of the Atlantic. I assume you mean easy/straightforward/obvious? ... You have to remember that east-of-the-Atlantic people find it difficult to understand why American quarter backs ram a baseball bat into a net and think they have scored a home run! <grin/> ... ok, back to serious stuff.

I'm curious how much if it is a conceptual problem 
> and how much is just unpleasant terminology.



I am not sure either. I do know that inconsistent use of terms at W3C is biting back more and more frequently. Inconsistent and imprecise use of terms in specifications is one cause of potential confusion.

One source of confusion in W3C specifications is eliding the notion of a "document" (as defined in XML 1.0) with some other representation of the information that such a document might contain. Imprecise use of terminology in W3C specifications is an entirely avoidable cause of confusion and misunderstanding. When terminology is used imprecisely the possibility that the imprecise terminology is concealing a conceptual landmine always persists. Creating a technically sound specification is necessary but not sufficient. Clear, precise and effective use of terms is also essential.

> Let me give the same answers to the same questions, but with XPath-centric
> terminology. I'll compare the volume of the ensuing screams. :-)


As I said earlier, I would have liked to see the technical issues / questions raised with you off list.

> ...
>
> AndrewWatt2000:
>
> >how many "root nodes" an XForms processor would see in, or associated
> with,a multinamespace XML document which contains three <xforms:model>
> elements.
>
> An XForms processor would effectively keep form data in (at least) one
> internal document per <xforms:model>. Each document has one root node.
> Multi-namespace doesn't have any bearing on this.


Micah, what you are calling an "internal document" I would call "a copy/separate XPath data model of part of the original document (or the XPath data model of it)". ... The "thingie" you are referring to is *not* a "document" as XML 1.0 defines a document! ...  Each of those copy XPath data models could legitimately, in my view, have its own root node.

I think multi-namespace does potentially have a little relevance here. Since the copy XPath data model is "excised" from the original document (or, more precisely, its XPath data model) then the question is whether or not namespace nodes are or are not copied across too. I doubt if that practically is important but a processor would have to decide what to do with those namespace nodes.


> >For each of those root nodes which an XForms processor sees (I assume that
> you will suggest there are three), can you provide the element type (name)
> of the document element node which is the child node of the root node
>
> [same answer] The document element node will always map to the user-chosen
> XML for the
> form. See below.


Saying that the document element node will always map to the user-chosen XML for the form is, to me at least, essentially meaningless.

If you recall, at the second Last Working Draft stage I pointed out that the XForms WG had not clearly defined what a "form" is in the context of XForms. That, to the best of my knowledge, remains the case.

Can you define what the XForms WG means by a "form"?

> >Can you also specify how many root nodes a non-XForms processor would see
> in the same document
>
> You'd need to read that specification to see what it says. Example: XSLT
> would take the document as a whole, with a single root node.


This issue was where I saw (with my previous understanding of what the XForms WG intended to say) the potential architectural issue for TAG. It seemed to me that the XForms CR was saying that XForms could add additional root nodes as it wished.

If it is the XForms WG's intention that these are separate / copy XPath data models I think that I am comfortable on that aspect of the issue.

But I am puzzled why you say that it would be up to the specification concerned.

As far as I understand XML 1.0 (with namespace accoutrements which were added later) the multi-namespace XML document, which happens to include elements from the XForms namespace, is a single XML 1.0 document. Yet you seem to see that as debatable or uncertain.

Can you explain further what you mean in this context?

> Let's make this really plain. Here's a portion of a document like what you
> described, with three <xforms:model>s.
>
> <html:html>
>   <html:head>
>     <xforms:model>
>       <xforms:instance>
>         <my:a/>
>       </xforms:instance>
>     </xforms:model>
>     <xforms:model>
>       <xforms:instance>
>         <my:b/>
>       </xforms:instance>
>     </xforms:model>
>     <xforms:model>
>       <xforms:instance>
>         <my:c/>
>       </xforms:instance>
>     </xforms:model>
> ...
>
> An XForms Processor will have three separate internal documents to keep
> track
> of. 


It seems to me that your terminology could serve to confuse rather than clarify. The term "internal" makes it seem to me that you are saying that the XML document (or the data model) has multiple root nodes again.

What I think you are trying to express is this: "In addition to the XPath data model for the containing document, including any elements in the XForms namespace, the XForms processor also has three separate copy XPath data models to keep track of. The document element node of each of the additional XPath data models corresponds to the child element of an <xforms:instance> element in the original XML document.". [If I understand the XForms CR correctly the precise relationship of when/whether a change in a node or its copy is to be reflected in the other has yet to be finally decided.]

Serialized, these would look like:
> 1) <my:a/>
> 2) <my:b/>
> 3) <my:c/>
>
> Note that:
> * All 3 documents have a single root node.


No. An XPath data model has a single root node. :) A document has a "root element" or a "document element".


> * All 3 documents have a single document element node, as a child of
> the root node


Again, No. An XML document has a single document element. The XPath data model for such an XML document has a single document element node.


> * The document element nodes are, respectively, my:a, my:b, and my:c


Well, that is the name of the element node.


> * The root node is special and has no representation in markup.


Hm. I think I know what you mean to say but the root node *is* represented in markup in the sense that an XPath expression possibly contained in such markup represents the root node by a single forward slash character.

But then we would have to agree what is or is not "markup". I suggest that we don't want to go there! :)


> * In all 3 documents, the html and xforms namespaced stuff is not
> present, and barring an extension function like document(), is inaccessible
> to XPath expressions.


This comment raises an interesting issue - at least I find it interesting. :)

What I think you are proposing to do is excise part of an XPath data model for the containing document and "glue" that to a new root node. Right? But, as well as excising it you are "trimming off" any namespace nodes that are not "user-defined" namespace nodes. Is that correct?

> Better?


I thought my descriptions were! <grin/>

Did I accurately express what the XForms WG's intentions are?

If I did, then I am significantly less uncomfortable about this than I was 36 hours ago. If I am continuing to misunderstand the XForms WG's intentions then please educate me further.

> .micah


I guess your mystery correspondents can decide whether or not they are happy and can stop "screaming" now. :)

Andrew Watt