Subject: [Netconf] [[email-masked]: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors]

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Sep 2008 21:21:16 +0200

Hi,

this might be interesting to look at and to keep an eye on.

/js

----- Forwarded message from [email-masked] -----

Delivered-To: [email-masked]
To: [email-masked], [email-masked]
Subject: RFC 5261 on An Extensible Markup Language (XML) Patch Operations
	Framework Utilizing XML Path Language (XPath) Selectors
From: [email-masked]
Date: Thu, 11 Sep 2008 11:57:10 -0700 (PDT)
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5261

        Title:      An Extensible Markup Language (XML) 
                    Patch Operations Framework Utilizing XML Path 
                    Language (XPath) Selectors 
        Author:     J. Urpalainen
        Status:     Standards Track
        Date:       September 2008
        Mailbox:    [email-masked]
        Pages:      40
        Characters: 78036
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-xml-patch-ops-04.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5261.txt

Extensible Markup Language (XML) documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems.  In order to send changes to an XML document, an entire copy
of the new version must be sent, unless there is a means of
indicating only the portions that have changed.  This document
describes an XML patch framework utilizing XML Path language (XPath)
selectors.  These selector values and updated new data content
constitute the basis of patch operations described in this document.
In addition to them, with basic <add>, <replace>, and <remove>
directives a set of patches can then be applied to update an existing
XML document.  [STANDARDS TRACK]

This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

----- End forwarded message -----
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Phil Shafer <[email-masked]>
Date: Thu, 11 Sep 2008 16:02:35 -0400

>this might be interesting to look at and to keep an eye on.

It's interesting, but seems like a draft, not an rfc.  Section 4.1
says they use "a restricted subset of the full XPath 2.0 recommendation",
but it isn't explicit about what that subset is.  The node step
doesn't mention axis or prefix notations and no limitation is put
on predicates.  The "namespace" in 4.2.1 is "foo:", which works but
is very confusing.  And 4.2.2 says:

   In contrast, in this specification, a selector without
   a prefix only matches one element, and it may match an element with
   or without a prefix but only if the namespace it's qualified with (or
   none) is an exact match.

---

From: Phil Shafer <[email-masked]>
Date: Thu, 11 Sep 2008 16:02:35 -0400

which
which is confusing and/or inconsistent (in that normal XPath selectors
match multiple elements, not just one).

That said, I like the functionality, and can see a <patch-config>
operation approaching in the distance.

Thanks,
 Phil

 is confusing and/or inconsistent (in that normal XPath selectors
match multiple elements, not just one).

That said, I like the functionality, and can see a <patch-config>
operation approaching in the distance.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2008 13:26:07 -0700

> operation approaching in the distance.

The idea of an XPath selector for <edit-config> instead
of inline XML was brought up in the past, and I think a draft
was published on it.

NETCONF has locking, validation, rollback, and a few other things
that go beyond patching an XML document, but I agree with you
that an edit-config style (XPath selector + replacement XML)
would be an interesting power saw.  Imagine the fun debugging
XPath based auto-edits :-)

>  Phil

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Sep 2008 13:26:07 -0700

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 11 Sep 2008 15:18:53 -0700

>>>>> On Thu, 11 Sep 2008 16:02:35 -0400, Phil Shafer <[email-masked]> said:

PS> That said, I like the functionality, and can see a <patch-config>
PS> operation approaching in the distance.

I've argued before that support for something like that is a requirement
for multi-operator-role environments where copy-config and global
operations can too easily get "bound" because of lack of privileges.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 11 Sep 2008 15:18:53 -0700

---

From: "tom.petch" <[email-masked]>
Date: Wed, 17 Sep 2008 18:26:46 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 11, 2008 10:02 PM
Subject: Re: [Netconf] [[email-masked]: RFC 5261 on An
ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path
Language (XPath) Selectors]

> says they use "a restricted subset of the full XPath 2.0 recommendation",

errr.... I'm confused.  The copy I am looking at, fresh from the rfc-editor,
says
"a restricted subset of the full XPath 1.0 recommendation.  "

I commented at IETF last call time that this I-D seemed to be specifying more
like XPath 2.0 functionality in its handling of default/no namespaces, and I see
that this section has since been wholy rewritten, adding a section on how this
use of XPath diverges from the formal specifications:-(

This is germane to the "belongs to" thread on Netmod, which touched on the 'no
namespace' issue in XPath.  In this thread, Lada raised the question of whether
yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up.
A discussion which is probably worth pursuing on netmod.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Wed, 17 Sep 2008 18:26:46 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 11, 2008 10:02 PM
Subject: Re: [Netconf] [[email-masked]: RFC 5261 on An

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Wed, 17 Sep 2008 14:39:09 -0400

>yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up.

The issue with XPath2.0 is the growth in size of the spec (6x iirc)
and the lack of availability of implementations.  One can wonder
if the two are related ;^)

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 17 Sep 2008 14:39:09 -0400

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Sep 2008 22:41:29 +0200

> if the two are related ;^)

In my opinion the best alternative by far is to use XPath 1.0 and accept
the way how it handles namespaces, without cheating.

By coincidence, I was looking at the spec of NVDL (one part of DSDL)
where they had a similar problem - they also needed something like
XPath, but simpler and with non-null default namespace. So they call it
matchPathExp and define everything in place - what it means that such an
expression matches etc. This is an option for YANG, too, although I
think it's not worth the effort.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Sep 2008 22:41:29 +0200

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C