Re: [netmod] xpath expressions in JSON

Andy Bierman <andy@yumaworks.com> Thu, 18 October 2018 19:45 UTC

Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6EF130DE5 for <netmod@ietfa.amsl.com>; Thu, 18 Oct 2018 12:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgtn4gcXaHw0 for <netmod@ietfa.amsl.com>; Thu, 18 Oct 2018 12:45:48 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF455130DDB for <netmod@ietf.org>; Thu, 18 Oct 2018 12:45:47 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id 63-v6so28842634ljs.4 for <netmod@ietf.org>; Thu, 18 Oct 2018 12:45:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lvas54jfLTCIoV+7vYXstv+BSzbH9p6pNZ8IT4GOfQM=; b=raEjb+GS50OMEN6DiDbPlH8M1dXaqM2nEFH9pUWo9uNeBEhNnS1lFY+AwwwGQ/URDB 7Ge3WmmvUlL6Hy+Bnu+xqjE7rxvOZ5dYun0lffxDp1i/i9l0RcGxTfeOzMpKobloZirb JdOkmq6+glUp4U2Qm0/AXs1W8DGFFmfbVyIhPPDiqT+s25qj/CpKaoIF4x+VRiaDqUbR UMHznKTvjXfHJRnXWGQ/+KKVwauzf4iEFbz4Woy2+LXcrBGGdl6+OgVWwFCaWNxWzupP wu+0EYi25bpmBxI18XTr1Skd5Xw3ZiFdiHoRBOst+NjN4nFpBcttuSfW0glm7RebnYx8 Ps0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lvas54jfLTCIoV+7vYXstv+BSzbH9p6pNZ8IT4GOfQM=; b=rZNZX1G0bmG+HbP28j+wWFp/N56JJWUVRiKI2sDZYYEY5BIjFJ2gpgEOQU42qCQFL4 JYw0OwAseor0wwqBGXrGqKH+NQRdJwj3Wd7N816nMMKLns+OYYnVuMoGQf7CNmv/N8bR UEQCABTAzub0WFrzD03g8s2huFkYjwChbCra4UDyWjpPg5BpzIACR8yoQsuU+bsU9Klz /pUXpHT2iK4cJmXARms2MIrNhhJd6I6d64WYKygaPF2EQWz9dmvcm2k0unqiYuVXc5qZ gGnRHYhJBBPxNWy1o8mJfdITYIDgAM52Mtqdbvy89go6NWbVkDCsXRmwaN0Bl+0oO4GC C9Mw==
X-Gm-Message-State: ABuFfojreKdl6+uuaGzq6jg35YacwvL66a13UCvEpb42Ljxvdih5iOUO /mEKFx0mTDRyQJdxlI6Ap0tsuPw937RM9sAIDfEOu0Kd
X-Google-Smtp-Source: ACcGV62Zlxc2Swp1OYrQJeZbDt/wuxMoag1DEJDxnM2QMMPSkrjuaYbTADUbJFxp6EXOaokyNM9ZdEsQSABHPw+1zC4=
X-Received: by 2002:a2e:9047:: with SMTP id n7-v6mr18339729ljg.10.1539891945921; Thu, 18 Oct 2018 12:45:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 18 Oct 2018 12:45:44 -0700 (PDT)
In-Reply-To: <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>
References: <20181011.181150.1840683183107627057.mbj@tail-f.com> <329f67ff-0774-0fd7-f630-7a01c7e7d3be@cisco.com> <20181012.103727.731509761734796510.mbj@tail-f.com> <20181018.123036.731934458688841323.mbj@tail-f.com> <70e76afa-59bd-249f-6b7c-4e5788806fc6@transpacket.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 18 Oct 2018 12:45:44 -0700
Message-ID: <CABCOCHRufR6S8NCp5n+UXgG0Y_OJ368XZZmzFR8wEHc0CLw+HQ@mail.gmail.com>
To: Vladimir Vassilev <vladimir@transpacket.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e097a05788608ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/06DRhCLUJvBcB_uD8ysukmfyO70>
Subject: Re: [netmod] xpath expressions in JSON
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 19:45:51 -0000

Hi,

I strongly agree that a new data type is needed (ypath1.0 or just ypath is
fine)
Adding new semantics or requirements to published data types is
unacceptable.

Also, we must get the type and module containing the data type right on the
first try.
No moving it later because the import looks bad. That said, a "quick
6991-bis" is unrealistic,
and a multi-year 6991-bis is unhelpful.

Should there be a canonical format, based on module-names as prefixes?
Consider how to compare 2 values using this data type.


Andy


On Thu, Oct 18, 2018 at 10:42 AM, Vladimir Vassilev <
vladimir@transpacket.com> wrote:

> Hi,
>
> Seems this discussion affects 10 draft modules using the xpath1.0 type.
> The proposed boilerplate description text that was not added to some RFC
> modules like ietf-netconf-monitoring@2010-10-04.yang
>
> should be as consistent as possible (or skipped based on the
> ietf-netconf-monitoring precedent) until a better alternative is available.
> Here is an example of a better alternative.
>
>    typedef ypath1.0 {
>     type xpath1.0;
>     description
>      "This type represents subset of XPATH 1.0 expressions
>       that apply to a data tree conforming to a YANG model.
>
>       Each encoding should allow conversion to an encoding
>       independent lexical representation where data node
>       prefixes are resolved to and substituted with module
>       names.
>
>       When a schema node is defined that uses this type, the
>       description of the schema node MUST specify the
>       context in which the expression is evaluated if it
>       is different from the default context.
>
>       The default context is as follows:
>
>         o  The set of variable bindings is empty.
>
>         o  The function library is the core function library, and
>            the XPath functions defined in section 10 in RFC 7950.
>
>         o  The context node is the leaf node.
>
>       ";
>     reference
>      "XPATH: XML Path Language (XPath) Version 1.0";
>   }
>
> That said I do not object to short-term application of alternative A as
> long as a long-term solution is on its way for future modules.
>
> Vladimir
>
> On 10/18/18 12:30 PM, Martin Bjorklund wrote:
>
>> Hi,
>>
>> Going back to the most urgent issue, what is this WG's recommendation
>> for the subscribed-notifications draft in NETCONF wrt/ their usage of
>> yang:xpath1.0 in filters?
>>
>> To summarize:
>>
>> We already have
>>
>>    o  instance-identifier in XML uses prefixes from the XML document
>>    o  instance-identifier in JSON uses module names as prefixes
>>    o  XPath in NETCONF filter uses prefixes from the XML document
>>    o  XPath in JSON query filter uses module names as prefixes
>>
>>
>> Alternative A:
>> --------------
>>
>> Use different encodings for "stream-xpath-filter" as well, depending
>> on if it is XML or JSON.
>>
>> We would do in SN:
>>
>>      o  If the node is encoded in XML, the set of namespace
>>         declarations are those in scope on the
>>         'stream-xpath-filter' leaf element.
>>
>>      o  If the node is encoded in JSON, the set of namespace
>>         declarations is the set of prefix and namespace pairs
>>         for all supported YANG modules, where the prefix is
>>         the YANG module name and the namespace is as defined
>>         by the "namespace" statement in the YANG module.
>>
>> Pro: the format is consistent within each encoding.
>>
>> Con: unclear how to handle other encodings.
>> Con: we keep using context-depending encodings.
>>
>> We could probably add that CBOR uses the same representation as JSON.
>>
>> Example in XML:
>>
>>    <stream-xpath-filter
>>        xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>        xmlns:ip="urn:ietf:params:xml:ns:yang:ietf-ip">
>>      /if:interfaces/if:interface/ip:ipv4
>>    </stream-xpath-filter>
>>
>> Example in JSON:
>>
>>    "stream-xpath-filter":
>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>>
>> Alternative B:
>> --------------
>>
>> Use a non-context depending encoding, with the module name as prefix.
>>
>> We would do in SN:
>>
>>      o  The set of namespace
>>         declarations is the set of prefix and namespace pairs
>>         for all supported YANG modules, where the prefix is
>>         the YANG module name and the namespace is as defined
>>         by the "namespace" statement in the YANG module.
>>
>> Pro: the format is independent from the protocol encoding
>>
>> Con: in XML, this leaf is treated differently from other XPath
>>       expressions, such as get-config filter and nacm rules.
>>
>> Example in XML:
>>
>>    <stream-xpath-filter>
>>      /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
>>    </stream-xpath-filter>
>>
>> Example in JSON:
>>
>>    "stream-xpath-filter":
>>      "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"
>>
>>
>> My proposal is A.  I think it is more important with consistency
>> within each encoding than across encodings.
>>
>> (This said, I would like to have a context-independent encoding of all
>> YANG types in the future.  But not now.)
>>
>>
>>
>>
>> /martin
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>