I question the use of XPath 1.0, when XPath 2.0 was approved at the start of
this
year. It seems short-sighted, a bit like choosing IPv4 over IPv6 (the difference
being that I have some acquaintance with the relative abundance of IPv4 and IPv6
but am not familiar with the relative deployment of XPath 1.0 and XPath 2.0).
Parts I find hard to follow, especially s4.2 Namespace Mangling
" While the XPath recommendation specifies that prefixes can be used in
location steps, it does not specify how associated namespace URIs are
discovered during these evaluations. "
XPath 2.0 says
'A QName in a name test is resolved into an expanded QName using the statically
known namespaces in the expression context'
which seems clear enough, using the language of XPath.
" In the patch operation framework QName [4] expansion within a location
step is evaluated according to the namespace declarations of the XML diff
document."
is an example of what I mean by being hard to follow - as elsewhere, a few more
commas would help.
" Note: It should be emphasized that prefixes within the XPath
selectors MAY be different than those of the initial XML document
because the matching of nodes is based on expanded names, i.e. a
prefix maps to a namespace URI and these URIs and local names MUST
be identical. For example, with a selector "p:foo", "p" maps to a
namespace URI and "foo" is the local name."
What I would like this to say is that
p:foo matches x:foo iff p: and x: map to the same namespace URI,
but I am unsure that that is what you are saying.
" In this framework, when a node test is "foo" and the patch operation
element has an in-scope default namespace declaration, a qualified
<foo> element from the initial XML document is being searched. That
is, the namespace URI of the expanded name of the located <foo>
element MUST then be identical compared to this default namespace
declaration. If there's not an in-scope default namespace
declaration within the evaluation context, an unqualified <foo>
element is located.
Note: By contrast, in XPath 1.0 a "foo" selector always locates an
unqualified <foo> element but in XPath 2.0 [10] also a qualified
one which is attached with the default namespace declaration."
I am confused by this. With a default namespace declaration in scope, I expect
XPath 2.0 to look for a match of both local name and namespace. "also" suggests
you expect a match of either local name and namespace or just local name - and
that that is the match algorithm that you are specifying for patch ie neither
XPath 1.0 or XPath 2.0.
" When the new added or updated elements contain namespace
declarations, the namespace nodes move unaltered from the XML diff
document to the patched XML document. Default namespace declarations
can only be added by this way but prefixed namespace declarations MAY
be added or removed with XPath namespace axis semantics shown later
in this document."
namespace axis semantics are deprecated in XPath 2.0 and so, I would suggest,
best avoided. But I do not think you need to refer to them. You have defined
your own semantics which just happen to resemble them:-)
And you could remove a default namespace by omitting the prefix, ie with
<remove sel="doc/foo/namespace::"/>
" Note: In practice, this namespace mangling means that an XML diff
document MUST only know the namespace URIs of qualified nodes, the
prefixes of the initial XML document are not significant unless
there are those overlapping namespace declarations. In other
words, regardless whether the prefixes of qualified elements of
the initial XML document are empty (default namespace attached) or
not, the XML diff document may remain the same."
I do not understand this. 'MUST only' sounds wrong - 'need only'? - and 'may
remain' - 'can remain'? But if the initial XML document uses namespace URIs,
either by default or by prefix, then the diff document must also know them, by
prefix or by default (not necessarily in the same way), at least for the nodes
it is selecting as part of the patching.
And a comment aimed more at the IESG. This business of updating parts of an XML
document seems to be cropping up in a number of places in the IETF with very
different solutions. Is there a need for more generic support and guidance on
how working groups should approach this? RFC3470 is fine but does not go far
enough for 2007 (IMHO).
Tom Petch
----- Original Message -----
From: "The IESG" <iesg-secretary@xxxxxxxx>
To: "IETF-Announce" <ietf-announce@xxxxxxxx>
Cc: <simple@xxxxxxxx>
Sent: Tuesday, September 11, 2007 9:19 PM
Subject: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup
Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath)
Selectors) to Proposed Standard
> The IESG has received a request from the SIP for Instant Messaging and
> Presence Leveraging Extensions WG (simple) to consider the following
> document:
>
> - 'An Extensible Markup Language (XML) Patch Operations Framework
> Utilizing XML Path Language (XPath) Selectors '
> <draft-ietf-simple-xml-patch-ops-03.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2007-09-25. Exceptionally,
> comments may be sent to iesg@xxxxxxxx instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-03.txt
>
>
>
>
> IESG discussion can be tracked via
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14052&rf
c_flag=0
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf