Re: [core] SenML JSON syntax (with multiple base objects)
Michael Koster <michaeljohnkoster@gmail.com> Tue, 20 October 2015 19:52 UTC
Return-Path: <michaeljohnkoster@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882971B2ACD for <core@ietfa.amsl.com>; Tue, 20 Oct 2015 12:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 r8koi2Z7ipF1 for <core@ietfa.amsl.com>; Tue, 20 Oct 2015 12:52:34 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 11D001B2A8F for <core@ietf.org>; Tue, 20 Oct 2015 12:52:27 -0700 (PDT)
Received: by padhk11 with SMTP id hk11so30366568pad.1 for <core@ietf.org>; Tue, 20 Oct 2015 12:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rKC7d0IWK2Z4cEeZXTDP5iJ09idaNqcrMA6HnlGa2fs=; b=MEJlM/4VR2jEAnauUg+lyF5nfswIv4fwr8yCPGIQM//15EiQga9hJJQoJBtGwl1AEw e4wfAK3Y0GWbINrwzBKN893U94U9TcRTrBiU1qDtQ8KJeFctuQgbfCWO/R/qzGBjladx 3eR+7zsSPtNBgDtf4AXFlZ9ieKaRsLzP82E8noqYpBySJyWSUtAK1L9HwDZZ8aoFIWfN 82ZG4/JHXIDhKeztjiA4VJCF6zsuKjUvCG6yF0tS2zUqZp8utkXAVLcZUKx4CG+hCo2X tQZLXv7KcW8X25WBefMAhH4tjXFnq+MNZ+9jnQe7+fOjWDX1tLkAkCxBR8tJU4/K221K siJQ==
X-Received: by 10.67.5.42 with SMTP id cj10mr5730007pad.128.1445370746753; Tue, 20 Oct 2015 12:52:26 -0700 (PDT)
Received: from [10.0.0.15] (108-201-184-41.lightspeed.sntcca.sbcglobal.net. [108.201.184.41]) by smtp.gmail.com with ESMTPSA id ns1sm5201172pbc.67.2015.10.20.12.52.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Oct 2015 12:52:25 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Koster <michaeljohnkoster@gmail.com>
In-Reply-To: <20151020184630.GI5451@hephaistos.amsuess.com>
Date: Tue, 20 Oct 2015 12:52:19 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <956423E0-BA70-4F4F-B0CD-6423203BC2BD@gmail.com>
References: <58C4BBDD-895C-4946-983A-405C6E5B760D@ericsson.com> <DAFB7C72-CF08-438E-B681-10918717A5D5@gmail.com> <20151020184630.GI5451@hephaistos.amsuess.com>
To: Christian Amsüss <c.amsuess@energyharvesting.at>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/0UQ0fW4L0HL10-ckRAKCuE4Egh0>
Cc: "draft-jennings-core-senml@tools.ietf.org" <draft-jennings-core-senml@tools.ietf.org>, core <core@ietf.org>
Subject: Re: [core] SenML JSON syntax (with multiple base objects)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 20 Oct 2015 19:52:35 -0000
Thanks for the reply! My comments below. Michael On Oct 20, 2015, at 11:46 AM, Christian Amsüss <c.amsuess@energyharvesting.at> wrote: > Hello Michael, > > On Tue, Oct 20, 2015 at 11:06:24AM -0700, Michael Koster wrote: >> Is the proposed format simpler because it removes the need to have an >> “e” tag and instead associates a data object with a base object by >> position in the array? > > the main advantage of the [{base}, [elements]] serialization is that > constrained devices have a chance of streaming decoding. With the base > and element data contained in an object, it is impractical to prescribe > a sequence of serialization (as it precludes the use of common JSON > serializers whose data structures don't know order inside an object). > > There has been some discussion at [1] and [2], which has led to the the > currently proposed syntax. > >> I think having base parameters and data array wrapped together in an >> object has some advantages, particularly when the object represents a >> set of resources as opposed to a sequence of measurements from a base >> resource. In this case the base name is the object or collection name >> and the array represents the resources in the collection. > > Granted, the grouping between the base name and the elements is not that > (visually) tight any more, but can still be expressed with the same base > name mechanisms. How is the multiple-resources case different from the > multiple-timestamps case here? It’s more than a simple visual relationship. I’m used to JSON tools that create an in-memory data structure that conforms to the JSON serialization. With the “old” SenML model, the elements of the object identified by “bn” are rendered as an array within the element identified by “bn” and tagged by “e”. The new construct more than just enables streaming, it forces serial interpretation, i.e. it *requires* streaming. I need to transform the in-memory representation if I want it to look the same as the familiar one. Not that I can’t do that, but to illustrate that it’s more than just a visual preference thing. It’s a matter of “impedance match” between the software machine and the in-memory representation I get from a JSON destringifier. > >> Additionally, this format can be extended using the same mechanism by >> adding another tag for another class of element. For example, let’s >> say I wanted to extend senml to add descriptive metadata in the form >> of RFC6690 hyperlinks encoded in link-format+json. I could easily add >> a “l” element extension for links and create a new content-format >> which can be processed and understood as a simple extension of SenML: > > That indeed has not come up in the previous discussion, and would not be > easily feasible with the new syntax. > > In my opinion, it raises the question of how generic SenML should > attempt to be. My personal view of it is that SenML is a way of > encapsulating several resource representations (be they of different > points in time or different resource) in a single message. With that in > mind, maybe the following would work for you (rephrasing your example > into senml-02 syntax, with comments): > SenML is already being used to represent simple collections in CoRE Interfaces, OMA LWM2M, and OIC. Whether to have it be extensible and evolvable or not is certainly a tradeoff against complexity and stream processing ability. I would lean toward evolvability. Would it make sense to create a new content-format that optimizes for streaming processing? > [ > { “bn”: ”/collection1/“ } > [ > /* the sv values are identical to what the client would receive > when GETting the respective /collection1/item as text/plain */ > {“n”: “item1”, “sv”, “value1”}, > {“n”: “item2”, “sv”, “value2”}, > {“n”: “item3”, “sv”, “value3”}, > {“n”: “item4”, “sv”, “value4”}, > > /* the "object value" is what the client would receive when > GETting /collection1/ with mime type > application/link-format+json */ > {"n": "", "ov": [ > {“href”: “item1”, “if”, “core.s”, “rt”: “type1”, “ct”: “50"}, > {“href”: “item2”, “if”, “core.s”, “rt”: “type2”, “ct”: “50"}, > {“href”: “item3”, “if”, “core.s”, “rt”: “type3”, “ct”: “50"}, > {“href”: “item4”, “if”, “core.s”, “rt”: “type4”, “ct”: “50"} > ]} > ] > ] > I was going to ask for “ov” for the ability to represent items that are themselves objects, so that’s a very useful feature for collections. However, representation of the links in a collection as a collection mapped to one of the items does not lead to a natural in-memory representation either. > That would need another data type in addition to string-, (numeric)- and > boolean value ("sv", "v", "bv") and thus allow encapsulating any other > JSON based response. Parsers in applications that don't expect "ov" > wouldn't even need to get more complicated, as they are already required > to ignore key-value pairs they don't understand. > > This still doesn't give a way to add arrays in parallel to the previous > "e" element, but for this application, it would automatically give > streamability also to your "l" list. > > What do you think of the above arrangement? > I think it’s a substantial compromise in the ability to represent data structure to get streaming processing ability. But I do like the idea of a “ov” element for object values. Best regards, Michael
- [core] SenML JSON syntax (with multiple base obje… Ari Keränen
- Re: [core] SenML JSON syntax (with multiple base … Michael Koster
- Re: [core] SenML JSON syntax (with multiple base … Carsten Bormann
- Re: [core] SenML JSON syntax (with multiple base … Christian Amsüss
- Re: [core] SenML JSON syntax (with multiple base … Michael Koster
- Re: [core] SenML JSON syntax (with multiple base … Cullen Jennings
- Re: [core] SenML JSON syntax (with multiple base … Carsten Bormann
- Re: [core] SenML JSON syntax (with multiple base … Alexander Pelov
- Re: [core] SenML JSON syntax (with multiple base … Carsten Bormann
- Re: [core] SenML JSON syntax (with multiple base … Alexander Pelov