Re: XPath 1.0 change proposal
James Clark <[email protected]> Sat, 16 Mar 2013 13:23:46 +0700
| Newsgroups | gmane.text.xml.xpath.general |
|---|---|
| Message-ID | <CANz3_Eah=wpYw9aOfUu_dukPzepWq7TQiRrtJHiVTW=ocY-N6w@mail.gmail.com> |
--14dae9ccd5948d56bd04d804cd81 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 15, 2013 at 10:26 PM, C. M. Sperberg-McQueen < [email protected]> wrote: ... > You seem to be establishing the principle that nodes share properties with > the corresponding constructs in the XML document (however one might > choose to define them) if and only if the definition of the data model > explicitly mentions those properties. > Nodes (a concept defined in XPath) have precisely the properties that XPath says they do. XPath specifies these properties in many cases by referencing the XML and XML Namespaces Recommendations. > On this reading, the normative reference to the XML spec seems to have > no function. > You've lost me. The normative reference is fundamental: the data model section is specifying how to construct a data model instance from a well-formed XML document, which is defined in the XML spec. It also relies upon it for, amongst other things, the definition of document order. > And this principle cuts away the ground underneath every argument thus > far brought forward for the claim that the parent and sibling relations > should be thought of as acyclic, even though the text does not say so. > XPath tells you, when you construct the node tree from a well-formed XML document, which nodes are parents/siblings of which other nodes. That is a completely sufficient specification. It will in fact be the case that, when you do so, that the parent/sibling relation so defined will be acyclic, but there is absolutely no need for XPath to say. If it would ease your concerns to add a sentence saying a node will never be a descendant of itself, I would have no problems with that. > > > 7 "The namespace nodes are defined to occur before the attribute > > nodes." Contradicts the normative statement of document order. > > > > This is giving you the definition of document order for attribute nodes. > > So - no textual demarcation between the sentences that are (on your > reading) merely fleshing out / repeating the normative statement of > document order, and this one, which modifies it by contradicting it? > > Well, bad drafting is not a criminal offense. It can happen to the best. > The drafting here could definitely be improved. If the WG thinks this drafting is so bad that it will cause real confusion, I would suggest the following minimal impact change to deal with it. There is an ordering, *document order*, defined on all the nodes in the document. For nodes other than attribute and namespace nodes, this order corresponds to the order in which the first character of the XML representation of the node occurs in the XML representation of the document after expansion of general entities. > > 10 "Nodes never share children: if one node is not the same node as > > another node, then none of the children of the one node will be the > > same node as any of the children of another node." Follows from > > assumption (a). > > > > That is addressing a misinterpretation that could arise because of > general entity expansions. > > But it fails to address the problem of distinctiveness adequately -- it > only addresses the case where the entity references occur directly > within different parents. > I think I agree with you here (yeah!). If I have understood you correctly, given the following XML document: <!DOCTYPE doc [ <!ENTITY e "<p/>"> ]> <doc>&e;&e;</doc> your point is that it is unclear whether the first and second child nodes of the "doc" element are distinct. I would address this by adding a sentence (following the quoted sentence above) along the lines of: "The identity of a child node is determined by its position amongst its siblings: the i-th child node is the same node as the j-th child node if and only if i is equal to j." > 11 "Every node other than the root node has exactly one parent, which > > is either an element node or the root node." Follows from XML 1.0 > > (assuming the usual usage of the word "parent" in XML contexts). > > > > > > This is giving a precise definition of the term parent, which is a > crucial for XPath. > > No, not precise at all. It is (on the usual reading of the spec) crucial > for > XPath that the parent relation be acyclic. Nothing here says so, implies > it, or even entails it. > The data model section tells you, when you construct the node tree from a well-formed XML document, which nodes are parents of which other nodes. When you so construct the node tree, the parent relation will always be acyclic. It is an extensional not an intensional definition. If you disagree, please given an example of a well-formed XML document for which it is unclear in the constructed node tree which nodes are parents of which other nodes, or in which the relationship is cyclic (ie an element is an ancestor of itself). > > I hope I have convinced you that the data model section is intended to > do nothing more than > > > > - explain how to construct the instance of the data model from an XML > document > > - define for such instances various key terms (parent, child, document > order, expanded-name, string-value etc) which are used in the rest of the > spec > > There are several problems here. > > First, the intent of the WG or the original editors can be reconstructed > (when and > to the extent that it can be reconstructed) by appeal to contemporary > documents > or other historical evidence. Nothing in your mail speaks directly to the > question of > intent, and any statement about the intent of the text is a non sequitur. > > Second, you seem to be falling victim to the intentional fallacy, an > elementary > error on textual interpretation which is common enough. The conscious or > unconscious intent of the authors of a text can be of historical interest, > but it > does not determine what the text means, if for no other reason than that > humans > do not always succeed in doing what they intend to do. > OK, so I should have said "does" instead of "intended to do". I believe I have demonstrated that my reading is completely consistent with all the text in the data model section. You have demonstrated that your reading is not. Normal principles of textual interpretation should therefore favour my reading. It's passably clear that this discussion is not going to persuade either of > us to > change our minds and that it's unlikely to provide any illumination to any > third > parties. Regrettably I do not seem to have been able to convince you of anything. However, you have convinced me that there is a defect related to node identity which should be corrected. You have also identified a couple of places where it would be perfectly reasonable for the WG to decide to add a clarifying phrase or sentence. I believe that the XPath 1.0 spec has a number of simple errors, which are > easily fixed; The word count of the new text you are proposing to add to Section 5 of XPath is approximately 50% of the word count of the current text of Section 5. It is a substantive piece of original work adding to XPath a formalization of the data model that makes it independent of the XML 1.0 and XML Namespaces Recommendations. This is an intricate, complex piece of work, which you have developed over a number of years. It is not simple, and it goes way beyond anything that could be described as fixing an error. Furthermore, your formalization is not the only possible one: there are other completely different ways to do this formalization (for example, by viewing the tree as a map from arrays of node positions to node properties). In my view it would be a major abuse of the W3C process to get this new, substantial, original work into a Recommendation status document by treating it as an errratum, thereby bypassing the extensive review and consideration that the W3C process would normally apply to such a piece of work. you deny that there are errors and assert at the same time that > fixing them would involve a much more extensive revision. > I do not deny that there are errors. I do say that your proposed revision is a much more invasive, risky one than is necessary to fix those errors. Recommendations are not academic papers. They serve practical goals: to allow implementors to independently create interoperable implementations, and to allow users to predict how those implementations will behave. XPath 1.0 is a very mature Recommendation with an extensive implementation track record. I therefore believe a cautious, conservative approach to changes should be adopted. Proposed changes should be separated out into small (changing a sentence or a phrase or two) changes, where each is precisely targeted to fix a specific point where there is something genuinely unclear to implementors or users. Each such change should have ideally have a concrete test case associated with it. I have given several examples above of the kinds of changes that I think might be appropriate at this stage. James --14dae9ccd5948d56bd04d804cd81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 15, 2013 at 10:26 PM, C. M. Sperberg-McQueen <span dir=3D"ltr">= <<a href=3D"mailto:[email protected]" target=3D"_blank">cmsmcq@bl= ackmesatech.com</a>></span> wrote:<div>...<br><div class=3D"gmail_quote"= ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex"> You seem to be establishing the principle that nodes share properties with<= br> the corresponding constructs in the XML document (however one might<br> choose to define them) if and only if the definition of the data model<br> explicitly mentions those properties.<br></blockquote><div><br></div><div>N= odes (a concept defined in XPath) have precisely the properties that XPath = says they do. XPath specifies these properties in many cases by referencing= the XML and XML Namespaces Recommendations.</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> On this reading, the normative reference to the XML spec seems to have<br> no function.<br></blockquote><div><br></div><div>You've lost me. The no= rmative reference is fundamental: the data model section is specifying how = to construct a data model instance from a well-formed XML document, which i= s defined in the XML spec. =A0It also relies upon it for, amongst other thi= ngs, the definition of document order. =A0</div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> And this principle cuts away the ground underneath every argument thus<br> far brought forward for the claim that the parent and sibling relations<br> should be thought of as acyclic, even though the text does not say so.<br><= /blockquote><div><br></div><div>XPath tells you, when you construct the nod= e tree from a well-formed XML document, which nodes are parents/siblings of= which other nodes. =A0That is a completely sufficient specification. =A0It= will in fact be the case that, when you do so, that the parent/sibling rel= ation so defined will be acyclic, but there is absolutely no need for XPath= to say. =A0 If it would ease your concerns to add a sentence saying a node= will never be a descendant of itself, I would have no problems with that.<= /div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">><br> > 7 "The namespace nodes are defined to occur before the attribute<= br> > nodes." =A0Contradicts the normative statement of document order.= <br> ><br> > This is giving you the definition of document order for attribute node= s.<br> <br> </div>So - no textual demarcation between the sentences that are (on your<b= r> reading) merely fleshing out / repeating the normative statement of<br> document order, and this one, which modifies it by contradicting it?<br> <br> Well, bad drafting is not a criminal offense. =A0It can happen to the best.= <br></blockquote><div><br></div><div>The drafting here could definitely be = improved. =A0 If the WG thinks this drafting is so bad that it will cause r= eal confusion, I would suggest the following minimal impact change to deal = with it.</div> <div><br></div><div><span style=3D"font-family:sans-serif;font-size:medium;= background-color:rgb(255,255,255)">There is an ordering,=A0</span><b style= =3D"font-family:sans-serif;font-size:medium;background-color:rgb(255,255,25= 5)">document order</b><span style=3D"font-family:sans-serif;font-size:mediu= m;background-color:rgb(255,255,255)">, defined on all the nodes in the docu= ment. <font color=3D"#ff6666">For nodes other than attribute and namespace = nodes, this order corresponds</font></span><span style=3D"font-family:sans-= serif;font-size:medium;background-color:rgb(255,255,255)">=A0to the order i= n which the first character of the XML representation of the node occurs in= the XML representation of the document after expansion of general entities= .</span></div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> > 10 "Nodes never share children: if one node is not the same node = as<br> > another node, then none of the children of the one node will be the<br= > > same node as any of the children of another node." =A0Follows fro= m<br> > assumption (a).<br> ><br> > That is addressing a misinterpretation that could arise because of gen= eral entity expansions.<br> <br> </div>But it fails to address the problem of distinctiveness adequately -- = it<br> only addresses the case where the entity references occur directly<br> within different parents.<br></blockquote><div><br></div><div>I think I agr= ee with you here (yeah!). =A0If I have understood you correctly, given the = following XML document:</div><div><br></div><div><!DOCTYPE doc [</div> <div><!ENTITY e "<p/>"></div><div>]></div><div><= ;doc>&e;&e;</doc></div><div><br></div><div>your point is t= hat it is unclear whether the first and second child nodes of the "doc= " element are distinct. =A0I would address this by adding a sentence (= following the quoted sentence above) along the lines of:</div> <div><br></div><div>"The identity of a child node is determined by its= position amongst its siblings: the i-th child node is the same node as the= j-th child node if and only if i is equal to j."</div><div><br></div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> > 11 "Every node other than the root node has exactly one parent, w= hich<br> > is either an element node or the root node." =A0Follows from XML = 1.0<br> > (assuming the usual usage of the word "parent" in XML contex= ts).<br> ><br> ><br> > This is giving a precise definition of the term parent, which is a cru= cial for XPath.<br> <br> </div>No, not precise at all. =A0It is (on the usual reading of the spec) c= rucial for<br> XPath that the parent relation be acyclic. =A0Nothing here says so, implies= <br> it, or even entails it.<br></blockquote><div><br></div><div>The data model = section tells you, when you construct the node tree from a well-formed XML = document, which nodes are parents of which other nodes. =A0When you so cons= truct the node tree, the parent relation will always be acyclic. =A0It is a= n extensional not an intensional definition. =A0If you disagree, please giv= en an example of a well-formed XML document for which it is unclear in the = constructed node tree which nodes are parents of which other nodes, or in w= hich the relationship is cyclic (ie an element is an ancestor of itself).</= div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> > I hope I have convinced you that the data model section is intended to= do nothing more than<br> ><br> > - explain how to construct the instance of the data model from an XML = document<br> > - define for such instances various key terms (parent, child, document= order, expanded-name, string-value etc) which are used in the rest of the = spec<br> <br> </div>There are several problems here.<br> <br> First, the intent of the WG or the original editors can be reconstructed (w= hen and<br> to the extent that it can be reconstructed) by appeal to contemporary docum= ents<br> or other historical evidence. =A0Nothing in your mail speaks directly to th= e question of<br> intent, and any statement about the intent of the text is a non sequitur.<b= r> <br> Second, you seem to be falling victim to the intentional fallacy, an elemen= tary<br> error on textual interpretation which is common enough. =A0The conscious or= <br> unconscious intent of the authors of a text can be of historical interest, = but it<br> does not determine what the text means, if for no other reason than that hu= mans<br> do not always succeed in doing what they intend to do.<br></blockquote><div= ><br></div><div>OK, so I should have said "does" instead of "= ;intended to do". =A0I believe I have demonstrated that my reading is = completely consistent with all the text in the data model section. =A0You h= ave demonstrated that your reading is not. =A0Normal principles of textual = interpretation should therefore favour my reading.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex"> It's passably clear that this discussion is not going to persuade eithe= r of us to<br> change our minds and that it's unlikely to provide any illumination to = any third<br> parties.</blockquote><div><br></div><div>Regrettably I do not seem to have = been able to convince you of anything. However, you have convinced me that = there is a defect related to node identity which should be corrected. =A0Yo= u have also identified a couple of places where it would be perfectly reaso= nable for the WG to decide to add a clarifying phrase or sentence.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">=A0 I believe that the XPath = 1.0 spec has a number of simple errors, which are<br> easily fixed;</blockquote><div><br></div><div>The word count of the new tex= t you are proposing to add to Section 5 of XPath is approximately 50% of th= e word count of the current text of Section 5. It is a substantive piece of= original work adding to XPath a formalization of the data model that makes= it independent of the XML 1.0 and XML Namespaces Recommendations. =A0This = is an intricate, complex piece of work, which you have developed over a num= ber of years. =A0It is not simple, and it goes way beyond anything that cou= ld be described as fixing an error. =A0Furthermore, your formalization is n= ot the only possible one: there are other completely different ways to do t= his formalization (for example, by viewing the tree as a map from arrays of= node positions to node properties). =A0In my view it would be a major abus= e of the W3C process to get this new, substantial, original work into a Rec= ommendation status document by treating it as an errratum, thereby bypassin= g the extensive review and consideration that the W3C process would normall= y apply to such a piece of work.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">you deny that there are error= s and assert at the same time that<br> fixing them would involve a much more extensive revision.<br></blockquote><= div><br></div><div>I do not deny that there are errors. =A0I do say that yo= ur proposed revision is a much more invasive, risky one than is necessary t= o fix those errors.</div> <div><br></div><div>Recommendations are not academic papers. =A0They serve = practical goals: to allow implementors to independently create interoperabl= e implementations, and to allow users to predict how those implementations = will behave. =A0XPath 1.0 is a very mature Recommendation with an extensive= implementation track record. =A0I therefore believe a cautious, conservati= ve approach to changes should be adopted. =A0Proposed changes should be sep= arated out into small (changing a sentence or a phrase or two) changes, whe= re each is precisely targeted to fix a specific point where there is someth= ing genuinely unclear to implementors or users. Each such change should hav= e ideally have a concrete test case associated with it. =A0I have given sev= eral examples above of the kinds of changes that I think might be appropria= te at this stage.</div> <div><br></div><div>James</div><div><br></div><div>=A0</div></div></div> --14dae9ccd5948d56bd04d804cd81--