Subject: Re: 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

From: "Tom.Petch" <[email-masked]>
Date: Tue, 18 Sep 2007 14:19:51 +0200

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
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
> [email-masked] mailing lists by 2007-09-25. Exceptionally,
> comments may be sent to [email-masked] 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Sep 2007 16:10:10 +0200

On Tue, Sep 18, 2007 at 02:19:51PM +0200,
 Tom.Petch <[email-masked]> wrote 
 a message of 135 lines which said:

> 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

I strongly disagree. Xpath 2.0 is *much* more complicated than Xpath
1.0. Among free software, there is little implementation (or even
plans) of 2.0. Xpath 2.0 is quite controversial.

The comparison with IPv4/v6 is wrong. If you start from scratch, IPv6
is no more complicated than IPv4 (and it is probably the
opposite). Xpath 2.0 is always much more difficult to implement (for
instance, it requires schemas).

> 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.

AFAIK, this is the first one to be specified at IETF. Other contenders
are:

* REX (W3C), which uses DOM events http://www.w3.org/TR/rex/

* Xquery update (W3C) http://www.w3.org/TR/xqupdate/

* XUpdate, which seems completely dead
http://xmldb-org.sourceforge.net/xupdate/

* DUL, there was an I-D, "A delta format for XML documents",
draft-mouat-xml-patch-00.txt, now expired
http://sourceforge.net/projects/diffxml

---

From: "Tom.Petch" <[email-masked]>
Date: Tue, 18 Sep 2007 19:04:46 +0200

----- Original Message -----
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Tom.Petch" <[email-masked]>
Cc: "ietf" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 18, 2007 4:10 PM
Subject: Re: Last Call: draft-ietf-simple-xml-patch-ops (An Extensible Markup

> plans) of 2.0. Xpath 2.0 is quite controversial.

OK, XPath 2.0 looks more attractive to me as a user but I am not familiar with
the uptake of XPath 2.0 (and does this make
my point that more IETF-wide guidance could be valuable eg, to set another  pack
of leverets running, XSD v RELAX NG v ...)

> http://sourceforge.net/projects/diffxml

Two that are current for me NETCONF, which offers XPath or subtree filtering to
update configuration information stored in XML, and ForCES which uses a
different approach to configure Network Elements specified via XML; I think I
have seen others in the Apps area.  I am not saying that these are doing exactly
the same, rather that I see the same issues with varying results.

Tom Petch

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 18 Sep 2007 12:19:29 -0700

I would be happy to encourage work on IETF-wide guidance for XML  
usage (I guess that's what I'm doing now?).  The Apps area has an XML  
directorate and supposedly we have some XML expertise to call on --  
sometimes we do XML usage reviews for the other IETF areas.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Sep 2007 18:10:36 +0200

> I strongly disagree. Xpath 2.0 is *much* more complicated than Xpath

Yes.

> 1.0. Among free software, there is little implementation (or even

Saxon!

> plans) of 2.0. Xpath 2.0 is quite controversial.

I think I disagree. What's controversial is XQuery :-).

> instance, it requires schemas).

I though that was truly optional.

> ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Sep 2007 18:10:36 +0200

Yes.

Saxon!

Best regards, Julian

---

From: "Tom.Petch" <[email-masked]>
Date: Thu, 20 Sep 2007 18:33:18 +0200

----- Original Message -----
From: "Lisa Dusseault" <[email-masked]>
To: "Tom.Petch" <[email-masked]>
Cc: "Stephane Bortzmeyer" <[email-masked]>; "ietf" <[email-masked]>
Sent: Tuesday, September 18, 2007 9:19 PM
Subject: Re: XML updates Re: 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

> sometimes we do XML usage reviews for the other IETF areas.

Lisa,

I have seen references to the XML directorate before but have not knowingly (in
Routing or Ops) seen output from it.  What I have in mind, what it might perhaps
do, is provide guidance - or to say that there is no clear guidance - in areas
such as
 - Schema language (XSD, RELAX NG,  ...)
 - namespaces (overuse of)
 - namespace prefix standardisation
 - element or attribute or text to instantiate an object
 - object identification (uniqueness, persistence, mutability, multiplicity of
..
 - using containers to provide scope for vendor extensions
 - selecting, adding, deleting nodes with XPath, filter expression, X.....
 - tables and table indexing
 - aggregation of objects for bulk operations
 - specifying conformance
 - versioningof object definitions
 - access control to objects

I see WGs struggling with these types of issues (although the WGs themselves may
not agree with my perception that it is a struggle)

At the back of my mind is the difference between ASN.1 and SMI (as used in MIB
modules).  Cutting down on the permissible ASN.1 constructs has made MIB modules
much less complex than they otherwise would have been (as described in RFC1155,
a brilliant piece of work).

RFC3470 is good, but I think that there is now a need for something more.

Tom Petch

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 20 Sep 2007 11:34:38 -0700

Hi,

This is a good starting point for an outline.  Why don't we take this  
to the Apps Discuss list ([email-masked]) unless anybody  
objects?  I know some people there don't read the IETF list, and  
anybody who's on the IETF list and not there now knows where  
discussion might occur.

You might call for participation, because without people like you  
contributing text and volunteering to edit and review, it can't get  
done :)

Thanks,

Lisa