XPath 1.0 change proposal

--20cf3071cf729ab85804d7e2d599
Content-Type: text/plain; charset=ISO-8859-1

Michael kindly pointed me to his change proposal for XPath 1.0, which he
tells me the XSLT WG is planning to consider its next meeting, and invited
me to send my comments to this list.

Although I appreciate Michael's work on formalizing the XPath 1.0 data
model, I do not think that at this stage a major rewrite of the XPath 1.0
data model is a good idea.  I would suggest that, after nearly 14 years, an
extremely conservative policy should be adopted towards changes: changes
should be made only when there is a genuine error that is manifested in
discrepancies between implementations or inconsistencies between
implementations and the spec.

The change proposal claims that it was a goal of XPath 1.0 for the data
model be defined without dependencies on XML 1.0.  I find this claim
bizarre given that XML 1.0 is referenced normatively and the data data
model definition is full of references to XML 1.0. The change proposal
seems to be claiming that XPath 1.0 is full of bugs in need of correction
because it does not meet a goal that it never had.

The change proposal also claims that it is a goal of XPath 1.0 that the
data model be defined formally.  This is clearly not the case.  XPath 1.0
does not make the slightest attempt to be formal.  Rather it aims to be
succinct and readily understandable.  The level of formality in the data
model definition is similar to that of the rest of the spec and of
companion specs (XML 1.0, XML Namespaces, XSLT 1.0).  It is also virtually
impossible to be really rigorous about the construction of the data model
from the XML document, without specifying this in the XML spec itself: for
each syntax production the XML spec would need to explain how to
corresponding data model was constructed.

I am also not convinced that in many cases the proposed wording changes are
in fact improvements.  If the WG does decide to go ahead with this change,
I can make some more detailed comments.  But for the moment, I would just
mention a couple of points.

XPath 1.0 does not constrain the root node to have exactly one element
child. In the case where the data model is constructed from an XML
document, there will of course be exactly one child.  But in other cases
(eg querying into a DOM DocumentFragment) it would be unhelpful to impose
such a restriction.  (XPath 1.0 is generally fairly loose -- for example,
it does not define conformance -- so as to provide maximum flexibility to
referencing specs.)

The reason why the spec uses terminology like "There is an element node for
every element" instead of referencing particular productions is because of
entity expansion.  For example, given

<!DOCTYPE doc [
<!ENTITY e "<x>foo</x>">
]>
<doc>&e;&e;</doc>

I am comfortable with saying (somewhat vaguely) that there are three
elements.  I am much less comfortable saying that there are three
occurrences of the "element" production (in fact, I would say it is clear
that there are only two occurrences of the "element" production).

James

--20cf3071cf729ab85804d7e2d599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Michael kindly pointed me to his change proposal for XPath 1.0, which he te=
lls me the XSLT WG is planning to consider its next meeting, and invited me=
 to send my comments to this list.<div><br></div><div>Although I appreciate=
 Michael&#39;s work on formalizing the XPath 1.0 data model, I do not think=
 that at this stage a major rewrite of the XPath 1.0 data model is a good i=
dea. =A0I would suggest that, after nearly 14 years, an extremely conservat=
ive policy should be adopted towards changes: changes should be made only w=
hen there is a genuine error that is manifested in discrepancies between im=
plementations or inconsistencies between implementations and the spec.</div=
>

<div><br></div><div>The change proposal claims that it was a goal of XPath =
1.0 for the data model be defined without dependencies on XML 1.0. =A0I fin=
d this claim bizarre given that XML 1.0 is referenced normatively and the d=
ata data model definition is full of references to XML 1.0. The change prop=
osal seems to be claiming that XPath 1.0 is full of bugs in need of correct=
ion because it does not meet a goal that it never had.</div>

<div><br></div><div>The change proposal also claims that it is a goal of XP=
ath 1.0 that the data model be defined formally. =A0This is clearly not the=
 case. =A0XPath 1.0 does not make the slightest attempt to be formal. =A0Ra=
ther it aims to be succinct and readily understandable. =A0The level of for=
mality in the data model definition is similar to that of the rest of the s=
pec and of companion specs (XML 1.0, XML Namespaces, XSLT 1.0). =A0It is al=
so virtually impossible to be really rigorous about the construction of the=
 data model from the XML document, without specifying this in the XML spec =
itself: for each syntax production the XML spec would need to explain how t=
o corresponding data model was constructed.</div>

<div><br></div><div>I am also not convinced that in many cases the proposed=
 wording changes are in fact improvements. =A0If the WG does decide to go a=
head with this change, I can make some more detailed comments. =A0But for t=
he moment, I would just mention a couple of points.</div>

<div><br></div><div>XPath 1.0 does not constrain the root node to have exac=
tly one element child. In the case where the data model is constructed from=
 an XML document, there will of course be exactly one child. =A0But in othe=
r cases (eg querying into a DOM DocumentFragment) it would be unhelpful to =
impose such a restriction. =A0(XPath 1.0 is generally fairly loose -- for e=
xample, it does not define conformance -- so as to provide maximum flexibil=
ity to referencing specs.)</div>

<div><br></div><div>The reason why the spec uses terminology like &quot;The=
re is an element node for every element&quot; instead of referencing partic=
ular productions is because of entity expansion. =A0For example, given</div=
>

<div><br></div><div>&lt;!DOCTYPE doc [</div><div>&lt;!ENTITY e &quot;&lt;x&=
gt;foo&lt;/x&gt;&quot;&gt;</div><div>]&gt;</div><div>&lt;doc&gt;&amp;e;&amp=
;e;&lt;/doc&gt;</div><div><br></div><div>I am comfortable with saying (some=
what vaguely) that there are three elements. =A0I am much less comfortable =
saying that there are three occurrences of the &quot;element&quot; producti=
on (in fact, I would say it is clear that there are only two occurrences of=
 the &quot;element&quot; production).</div>

<div><br></div><div>James</div><div><br></div><div><br></div><div><br></div=
>

--20cf3071cf729ab85804d7e2d599--