[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [unide-dev] Conclusion issue #35
|
You're right that github issues should be the basis of public discussions.
Currently, it's us three who represent the major interested parties and I appreciate your input! Yet, even I have trouble following the current thread. So I believe that it would even be helpful for others if we sync up first and document the outcome there.
Let's find time for a call next week (Tuesday?) when Steve is back?
Mit freundlichen Grüßen / Best regards
Axel Meinhardt
(BCI/ECM2, Technical Lead Ecosystem)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
-----Original Message-----
From: Bor Gonzalez Usach <Bor.Gonzalez.Usach@xxxxxxxxxxxxxxxxxxxx>
Sent: Mittwoch, 30. Mai 2018 09:39
To: Meinhardt Axel (BCI/ECM2) <Axel.Meinhardt@xxxxxxxxxxxx>; Stephen Bryant <Stephen.Bryant@xxxxxxxxxx>
Cc: unide developer discussions <unide-dev@xxxxxxxxxxx>
Subject: AW: Conclusion issue #35
Hello all,
Axel, I think it would be better to open an issue to discuss each detail. Each issue must be as small and focused as possible in order to avoid going down the rabbit hole.
Discussing via emails is not the best way IMO. Issues work as documentation (in case somebody wants to recall why certain decisions were taken), and also allow people who are not interested in a given topic to ignore it. Alternatively the forum could be used.
Best,
Bor
-----Ursprüngliche Nachricht-----
Von: Meinhardt Axel (BCI/ECM2) <Axel.Meinhardt@xxxxxxxxxxxx>
Gesendet: Mittwoch, 30. Mai 2018 09:20
An: Stephen Bryant <Stephen.Bryant@xxxxxxxxxx>; Bor Gonzalez Usach <Bor.Gonzalez.Usach@xxxxxxxxxxxxxxxxxxxx>
Cc: unide developer discussions <unide-dev@xxxxxxxxxxx>
Betreff: RE: Conclusion issue #35
Thanks Bor for you good summary and Steve for even checking email while on vacation - don't get in trouble with your family ;-) We are indeed getting close!
== datatype==
I think an array of measurements should not be of mixed type. In order for the parser to not having to dynamically check the type, my idea was to default to number. In other case (JSON type + base64), that would have to be indicated. So also dataType=string would need to be specified explicitly (e.g. to indicate it's not a base64 string).
== unit ==
Unit doesn't need to be an extra hierarchy but just one field. The namespace on context level would be a namespace of the context (=dataType) for me, thought. That namespace could then contain a meta-model describing the specific interpretation and limitation of that measurements context. The interpretation of the unit field could be one of these aspects, but not necessary limited to it.
Is that an option?
Mit freundlichen Grüßen / Best regards
Axel Meinhardt
(BCI/ECM2, Technical Lead Ecosystem)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
-----Original Message-----
From: Stephen Bryant <Stephen.Bryant@xxxxxxxxxx>
Sent: Dienstag, 29. Mai 2018 22:11
To: Bor Gonzalez Usach <Bor.Gonzalez.Usach@xxxxxxxxxxxxxxxxxxxx>; Meinhardt Axel (BCI/ECM2) <Axel.Meinhardt@xxxxxxxxxxxx>
Cc: unide developer discussions <unide-dev@xxxxxxxxxxx>
Subject: Re: Conclusion issue #35
Hi guys,
I'm away on holiday with the family, so my time is a little limited.
On 29/05/2018 17:38, Bor Gonzalez Usach wrote:
> Hi Axel and Stephen,
>
> I'm not sure I can make it, and Stephen hasn't replied so far. so
> maybe we can try to do this via mail.
>
> Everybody has explained his opinion on each subtopic, and this is the
> summary:
>
> ·Binary data: you both agree that there should be a dataType field
> describing the encoding mechanism (like base64). I have the feeling
> that could be better off in the description field, (and thus also
> avoid some minor issues, like having a boolean value and a dataType=base64).
> However, it isn't a big deal to me. So, the winner is*:* *we have
> dataType field, and must be used only for binary encoded strings*
> (maybe it should be named binaryEncoding or similar?).
>
> The rest of types (bools, numbers, strings, .) rely on the JSON encoding.
I agree with this.
> ·How to represent unitID and namespace: they can be placed directly
> under context.field (flat), as a subobject in context.field.unit
> (nested), or a mix of both depending on whether there is a namespace
> or not (mixed).
>
> Stephen, you seem to think that flat and nested are ok. I prefer flat
> (I don't see any special value in this grouping, and we can save a
> class in the implementations), but nested is fine by me. However I
> would really avoid the mixed option. *So Axel it is up to you to
> decide, but I really think you should go for either flat or nested.*
Agree with this too.
> ·Unit ID restrictions: Stephen, you think that any string should be
> accepted as an ID, and I think they should be restricted because free
> text does not work IMO very well as ID (especially if you let Unicode
> into the party), and Axel, you seem to think too that no restrictions
> are necessary. *So, free strings it is* =)
Looks like we have reached a conclusion!
Best regards,
Steve
<b>Stephen Bryant</b><br></font><font face='Arial' size='1' color='#999999'>B.Sc.<br>Business Unit Networking<br>BN/D<br>
[http://assets.balluff.com/JPG_original_size/E-Mail-Footer_Vertrieb_Logo.jpg]
Balluff GmbH · Schurwaldstrasse 9 · 73765 Neuhausen a.d.F. · Germany Phone +49 7158 173-8388 · Fax +49 7158 5010 · stephen.bryant@xxxxxxxxxx<mailto:stephen.bryant@xxxxxxxxxx> · www.balluff.com<http://www.balluff.com>
Place of incorporation/Sitz der Gesellschaft: Neuhausen a.d.F., Germany · Register court/Registergericht: Amtsgericht Stuttgart, Germany Trade register/Handelsregister: HRB 214038 · Managing directors/Geschäftsführer: Michael Unger, Katrin Stegmaier-Hermle, Florian Hermle Chairman board of directors/Vorsitzender des Aufsichtsrats: Dr. Wolf Münstermann · VAT ID/USt-ID: DE213 402 337
[http://assets.balluff.com/JPG_original_size/E-Mail-Footer_Vertrieb_Claim.jpg]
