Re: [core] [T2TRG] Review of CoRAL

Klaus Hartke <hartke@projectcool.de> Sat, 10 November 2018 09:09 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11ED130E43 for <core@ietfa.amsl.com>; Sat, 10 Nov 2018 01:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no
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 1rmc9qKcwJ78 for <core@ietfa.amsl.com>; Sat, 10 Nov 2018 01:09:30 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8597::]) (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 91F8B130E13 for <core@ietf.org>; Sat, 10 Nov 2018 01:09:30 -0800 (PST)
Received: from mail-qk1-f174.google.com ([209.85.222.174]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gLPGj-0007eZ-1z; Sat, 10 Nov 2018 10:09:29 +0100
Received: by mail-qk1-f174.google.com with SMTP id o89so5842985qko.0 for <core@ietf.org>; Sat, 10 Nov 2018 01:09:29 -0800 (PST)
X-Gm-Message-State: AGRZ1gKQoqbb3dWw4i33YwpUymAMqIGHR+7v5zAijG6iLY22JiTbG7qb PBkymcloXjEKmp8ilaQR6reSHx5W8/KPw5DBSAg=
X-Google-Smtp-Source: AJdET5dui2B/ts3Xb3JcJnQL8L+dfenGh1QGXIvO/Apm96cK2grQx7gslz0XIIbgsa+eprJYknDyiqLG/tihV8jQkrY=
X-Received: by 2002:ac8:3986:: with SMTP id v6mr11606369qte.1.1541840968022; Sat, 10 Nov 2018 01:09:28 -0800 (PST)
MIME-Version: 1.0
References: <20181031164534.GA4995@hephaistos.amsuess.com> <CAAzbHvYPRLMZFh2Yi7jwM8ZzVMXcLmqe20Qeo2LjD9xCu4=9QA@mail.gmail.com> <20181105120109.GC12165@hephaistos.amsuess.com>
In-Reply-To: <20181105120109.GC12165@hephaistos.amsuess.com>
From: Klaus Hartke <hartke@projectcool.de>
Date: Sat, 10 Nov 2018 10:08:55 +0100
X-Gmail-Original-Message-ID: <CAAzbHvajs0LgApHX6BgV-FngU51G+mGxbYCpyTqt_pJwchDGFQ@mail.gmail.com>
Message-ID: <CAAzbHvajs0LgApHX6BgV-FngU51G+mGxbYCpyTqt_pJwchDGFQ@mail.gmail.com>
To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= <christian@amsuess.com>
Cc: "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541840970; ff673390;
X-HE-SMSGID: 1gLPGj-0007eZ-1z
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/w0LkRNh2ir5vh7HUbws3GZqJTT0>
Subject: Re: [core] [T2TRG] Review of CoRAL
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Nov 2018 09:09:32 -0000

Christian Amsüss wrote:
> > The draft currently specifies that a base IRI is resolved against the
> > current context IRI, not the previous base IRI.
>
> Thanks; likewise, I missed updating the current relation number. Both
> being fixed.

I just checked how Turtle does it, and it seems that in Turtle a base
IRI is resolved against the previous base IRI. The difference is as
follows:

Document without base IRIs:

    item <foo/a>
    item <foo/b>
    item <bar/c>
    item <bar/d>

Document with base IRIs relative to context IRI:

    #base <foo/>
    item <a>
    item <b>
    #base <bar/>
    item <c>
    item <d>

Advantage: Since link targets are more likely to be relative to the
context than to the previous link targets, this should generate
slightly more compact CBOR representations.

Document with base IRIs relative to previous base IRI:

    #base <foo/>
    item <a>
    item <b>
    #base <../bar/>
    item <c>
    item <d>

Advantages: Since the context IRI is not used after the first base IRI
directive, a processor can reuse the memory for the context IRI to
store the base IRI instead of having to allocate memory for both. It
would match the intuition of people who are familiar with Turtle.

Would it make sense to switch?

Klaus