datatype requests #37
Comments
|
Concerning the URI part of the issue, we may need to discuss the scope. URIs cover more than web addresses (see RFC3986 - https://datatracker.ietf.org/doc/rfc3986/). Does the datatype need to address all URIs in general or just web addresses? For example, the following are all URIs: |
|
Concerning the Array/Map part of the issue, it's not clear what "based on experience with CBOR" means in the context of an information model, since CBOR is a specific data format. I'm thinking the intention is to describe the datatypes in a way that makes implementation in CBOR easier. If that's the case, then we could pattern Map and Array on JSON, since CBOR can be use to define compact representations of JSON structures. |
|
"based on experience with CBOR": While CBOR is a encoding/dataformat, it can be described using the language CDDL - maybe that was implied here?. Because, CDDL can already represent both JSON and CBOR structures natively (and JSON uses a totally different serialization). This is for two primary reasons:
In any case, the characteristics of arrays and map are the same in both encodings. If those are meant, I agree that the semantics can probably be derived from the corresponding definitions, as Mike already suggested: https://tools.ietf.org/html/rfc4627#section-2.2 |
|
I think that this could probably have been written just as easily as "based on experience with JSON". I just read it as we should have these types available because we have found them useful. They are available (I think) as primitives (ordered vs unordered lists?) so I think that it has been satisfied. |
|
Well, as the definition says: Maps are an unordered set of AVP that only allows exactly one instance of each attribute, but provides unambigous semantics. An array is an ordered set of values that allows combination of sequences of values with the same type, but therefore also allows for ambigous semantics. I am in doubt that the ordered and unordered lists defined by the IM draft are either of those. I am also not sure if we need them, though. In general, it does not hurt to enable the use of JSON, I'd say. |
|
An unordered list is defined as - here are a set of name and values pairs that can occur in any order in the list. To me this is semantically the same as a MAP. An ordered list is defined as - here are a set of name and value pairs that can occur in a fixed order in the list. This is basically the same thing as what an array looks like assuming that you have the ability to deal with elements in the middle that are absent. This could be done by the use of tagging or nil points in the array to say that the field is not there. That seems to be to be the semantic equivalent of an array, but I can see some people might not agree with that. |
|
Since this is in regard to an IM, the most generic concept is a collection.
Lists, maps, trees, and other data structures are all types of collections.
A collection is a group (not necessarily a set!) of zero or more data items
that have some shared semantics, and which need to be operated on together.
A list represents a countable number of values. Lists are typically
ordered, but if you want to define ordered and unordered lists, then the
key difference is that the former defines a function that controls the
occurrence (i.e., order) of each member of the list, whereas the latter
either has no such function, or the function is random (I dislike having a
random function). Lists typically do NOT have distinct values - both
ordered and unordered lists can have duplicates.
Lists are typically finite. Streams are infinite lists.
An array is a collection of elements, where each element is selected by one
or more keys (indices). Hence, an array is NOT the same as a list.
A dynamic array is an array whose size can change at runtime.
A map (a.k.a dictionary) is a collection of {key, value} pairs, such that
each key appears no more than once in the collection. Hence, it is NOT the
same as an array - their behaviors are different, and arrays can be
multi-dimensional.
From an IM point-of-view, I would suggest that we use abstract data types
to define these more precisely, though this may be too formal for the WG.
Basically, an Abstract Data Type is a mathematical model of a data
structure where its semantics (i.e., behavior) is defined in terms of
possible values and operations on data of this type from the point-of-view
of a **user** of the data. This is contrasted with data structures, which
are defined from the point-of-view of the **implementor**.
HTH,
John
…On Tue, Jan 10, 2017 at 3:10 PM, Jim Schaad ***@***.***> wrote:
An unordered list is defined as - here are a set of name and values pairs
that can occur in any order in the list. To me this is semantically the
same as a MAP.
An ordered list is defined as - here are a set of name and value pairs
that can occur in a fixed order in the list. This is basically the same
thing as what an array looks like assuming that you have the ability to
deal with elements in the middle that are absent. This could be done by the
use of tagging or nil points in the array to say that the field is not
there. That seems to be to be the semantic equivalent of an array, but I
can see some people might not agree with that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKbE0e2qQ7JMzX1L94Ym6GLo3_-q_Owrks5rRA_TgaJpZM4Hw9Um>
.
_______________________________________________
sacm mailing list
***@***.***
https://www.ietf.org/mailman/listinfo/sacm
--
regards,
John
|
|
Can you generate a pull request so we can see how this would be different from what is current in the document? |
At the 3/9/16 SACM Virtual Interim Meeting, there was a request for the following features with respect to datatypes in SACM.
If anyone else has datatype requests for SACM, feel free to add them to this tracker.
The text was updated successfully, but these errors were encountered: