Re: [netmod] rfc6991bis: yang:xpath1.0

Andy Bierman <andy@yumaworks.com> Fri, 24 July 2020 16:38 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 ED0A43A0FBB for <netmod@ietfa.amsl.com>; Fri, 24 Jul 2020 09:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 GQ8qnWSi6wGx for <netmod@ietfa.amsl.com>; Fri, 24 Jul 2020 09:37:59 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 11C773A0FB5 for <netmod@ietf.org>; Fri, 24 Jul 2020 09:37:58 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id v15so980376lfg.6 for <netmod@ietf.org>; Fri, 24 Jul 2020 09:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XlWtorwxUhQbQaXjDuGtPTxnaPlP/AKoon0FyITaqt0=; b=K9Y8O8f5QHPW/hoQaLGZkT2SJT+COw2vJmQZPimWNEQVUCsnCwiELj3ilSXsjW74MI ELboGBY5ypggOES+C1mEF48mGE/GZ4wC0hWtgGleTkPK3PnLh4Wbe1amUx5MTSkCA0oJ /kbrCcjlqK5iT9eVheZ+0I3u/gGhTWC5n48T7T3S5ocG1i8ZgHkhmpT7lK8tE2/2gHN8 LIKRez/7cWz01lZmlu+cpDT8qPRtDOL518xBpITQTDoG9tkr29p9XsMMYP5HydxqhZ0q 7c4bLyV9ei7zu1ZxdkjBeFGmOv7t5iRt5eTRqOxk7+HXp9g+j5EAyv1fpN5U6vglhBlW CVCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XlWtorwxUhQbQaXjDuGtPTxnaPlP/AKoon0FyITaqt0=; b=t7A84akvbksBtTYxWAqQSPbYgZOEN4OO+Wl7zAMDvb9C4bFkBtHG5eKSwAYbJQ2ZjO 8XT307elV0E9yvU5YHhdkv5g2gdER5hnW57y7HSrMEKT6AoAdXt3bZfwS4oJEWrnrwXQ QoQRW8rZITnk/1zDWmwmzPPLL+uiJ6XlI8P5Bc8FfuxmI+xfOZA7RkF6zk0sa12T91r3 1BxzYUeH1M3PMxPIF45Q6lcc7ot4heKPQGBVmVdqMkLh2gm7EebXdTqBdnh9jRdulVIk zhPnBTl1P3p+hw1YFZBSKT7Y15X4Rou+Rm07AR5NHkb1qSTLl9ZWtmWGEvKaqb+2PHYe KoQw==
X-Gm-Message-State: AOAM533mOoGir8ERmNkHQhuwgkmii7p8gvxpvWtx7L0GNmd3u7Xbyuia gpnrzIwK6qJpTgUbsd9QZqR/2VWCe8be/VX67+klzw==
X-Google-Smtp-Source: ABdhPJxmQmg2c+Kps0iWUeEhOfaCUdQWVAnj2EVu978Pe+D7u261ygIuCQAtU0d2UQwX2OVwyAX655NhPO5d9DPA6lQ=
X-Received: by 2002:a05:6512:330c:: with SMTP id k12mr5413883lfe.151.1595608676843; Fri, 24 Jul 2020 09:37:56 -0700 (PDT)
MIME-Version: 1.0
References: <2751efb1-d276-8c49-4697-87de2bb379e8@lightside-instruments.com> <86a37242-a85d-f4a6-1db6-c79d861f76fb@lightside-instruments.com> <CABCOCHQ-=-2yb2iA6sRMir6MvvQfGzyb4Nx3MFFYof6By4jKLg@mail.gmail.com> <20200724094023.u5gqt6fnfjjtjktm@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200724094023.u5gqt6fnfjjtjktm@anna.jacobs.jacobs-university.de>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 24 Jul 2020 09:37:45 -0700
Message-ID: <CABCOCHS3Sbp=QME-9Eg57_AscTYn5KfYvX73QgiAO4hPjzZr=w@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, Vladimir Vassilev <vladimir@lightside-instruments.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000625f2a05ab3298ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gHMlvcCnUtgu3Ps6WV0QX4JaQGM>
Subject: Re: [netmod] rfc6991bis: yang:xpath1.0
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: Fri, 24 Jul 2020 16:38:01 -0000

On Fri, Jul 24, 2020 at 2:40 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Jul 18, 2020 at 09:00:42AM -0700, Andy Bierman wrote:
> > On Sat, Jul 18, 2020 at 8:42 AM Vladimir Vassilev <
> > vladimir@lightside-instruments.com> wrote:
> >
> > > On 17/07/2020 21.14, Juergen Schoenwaelder wrote:
> > >
> > > > - How do we deal with xpath expressions in other encodings
> > > > such as JSON. Do we assume an xpath context populated with
> > > > module names such that module names can be used to qualify
> > > > path expressions. This may need discussion and/or a new
> > > > definition.
> > > >
> > > > - This interacts with the definition of node-instance-identifier.
> > > >
> > > > - Options: (i) Leave this definition as it is. (ii) Detail how this
> > > > type work with encodings that use module names instead of prefixes
> > > > to qualify names.
> > > >
> > > > - Proposal: ?
> > >
> > >
> > > How about leaving the xpath1.0 type definition as it is and specifying
> a
> > > canonical form for the node-instance-identifier where namespace
> prefixes
> > > must be module names.
> > >
> > >
> > Since (i) is the only BC option why is (ii) even being considered?
> > Of course a new type name is needed to change the XPath syntax
> > to something that is not backward-compatible.
> >
>
> The idea was not to propose something non-backwards compatible but to
> try to explain how xpath1.0 values work with non-XML encodings. But
> perhaps this is 'unexplainable' in the sense that people deal with
> this in different ways.
>
>

IMO it is better to use a new type definition where the prefixes MUST be
module names
rather than overload a widely deployed type definition with semantics that
the prefixes
MAY be module names.

I prefer a new node-instance-identifier typedef, based on RFC 8040 sec.
3.5.3,
but that is another discussion.


/js
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>