[DISCUSS] Streamline the address format over all drivers

[Christofer Dutz <ch...@c-ware.de>]

Hi all

I’m playing a bit with my UI thingy and am currently implementing some Tag editor.

I have inputs for the address string, the type name as well as the array-info and I need to generate the full address string for all drivers from these fragments.

Currently it seems not all drivers follow the same structure.

I did a survey on LinkedIn on the various aspects of how array-notations could be processed.

Even if the survey is not over yet, it does look as if the following seems to align with most people:

[2..5] implicates elements 2,3,4,5
[2..5, 6..9] is a multi-dimensional array

Ideally, we should probably also understand things like, but when serializing we should use above notations:

[5] is a shorthand for elements 0, 1, 2, 3, 4
[4][6] (A more IT-like array definition)

Now for integrating things in other tools, I think it would be good if all address strings had the following structure (similar to how our connection strings work)

{protocol-dependent-address}:{typename}{[array-syntax]}{options}

The type-name could be omitted for protocols such as ADS where the address already defines the type.
In that case we should probably also have API types for accessing these parts of the addresses.

What do you think?

Chris




And for STRING and WSTRING to also have optional string-lengths in round brackets behind the STRING or WSTRING.

What do you think?

Chris

AW: [DISCUSS] Streamline the address format over all drivers

[Christofer Dutz <ch...@c-ware.de>]

So, I just took the time to evaluate the results of my LinkedIn question.

There were 25 people voting and I think we can make 96% of all people happy with this:

The array notation is:

[lower-bound .. upper-bound] = ��[2..5]��
However, it should still be possible to enter something like this: ��[5]�� but we internally interpret that as [0..4]

With my multi-dimensional array question, things were not quite as simple ;-)
It is the IEC notation to write them as: [1...3, 4...5], however more people voted for [1...3][4...5]
I was expecting the people voting for the IEC option to be more OT guys and the other to be IT guys, but I couldn��t really spot that pattern.

Here I would opt for going with the majority and use the [1...3][4...5] notation. However, should the parser be able to also read [1...3, 4...5].

What do you think? Would that be a good way to go?

Chris




Von: Jinlin Hong <my...@gmail.com>
Datum: Donnerstag, 6. Februar 2025 um 09:07
An: dev@plc4x.apache.org <de...@plc4x.apache.org>
Betreff: Re: [DISCUSS] Streamline the address format over all drivers
Thank you for your reply, and my apologies for mixing up the bit and array
discussions.
Regarding the array syntax, I think it��s great to allow users to customize
the return format. That said, [5] and [4][6] do indeed represent the same
thing, haha.

Jinlin

Christofer Dutz <ch...@c-ware.de> � 2025��2��6�� �L�� ����3:19������

> Replying to both in one email here.
>
> Regarding the array notation:
> I am proposing to use one format. So if you have a tag and ask it to
> return the string representation, you'll only get one format.
>
> I'm more proposing to make the parser a bit more flexible and support more
> options as input to allow some OT engineering addresses parsable without
> having to reformat all addresses.
>
>
> I think the bit stuff is a completely different discussion. Happy to do
> this in parallel... Let's stick to arrays in this discussion ;-)
>
> Chris
>
>
> Gesendet von Outlook f��r Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Jinlin Hong <my...@gmail.com>
> Sent: Thursday, February 6, 2025 2:50:34 AM
> To: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Subject: Re: [DISCUSS] Streamline the address format over all drivers
>
> We have previously discussed this, and some of the conclusions might no
> longer apply: Cleanup of how we handle all the bit-related fields
> <
> https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
> >.
> In my opinion, regardless of the final rules, we just need to finalize it.
>
> Christofer Dutz <ch...@c-ware.de> � 2025��2��5�� �L�� ����2:27������
>
> > Hi all
> >
> > I��m playing a bit with my UI thingy and am currently implementing some
> Tag
> > editor.
> >
> > I have inputs for the address string, the type name as well as the
> > array-info and I need to generate the full address string for all drivers
> > from these fragments.
> >
> > Currently it seems not all drivers follow the same structure.
> >
> > I did a survey on LinkedIn on the various aspects of how array-notations
> > could be processed.
> >
> > Even if the survey is not over yet, it does look as if the following
> seems
> > to align with most people:
> >
> > [2..5] implicates elements 2,3,4,5
> > [2..5, 6..9] is a multi-dimensional array
> >
> > Ideally, we should probably also understand things like, but when
> > serializing we should use above notations:
> >
> > [5] is a shorthand for elements 0, 1, 2, 3, 4
> > [4][6] (A more IT-like array definition)
> >
> > Now for integrating things in other tools, I think it would be good if
> all
> > address strings had the following structure (similar to how our
> connection
> > strings work)
> >
> > {protocol-dependent-address}:{typename}{[array-syntax]}{options}
> >
> > The type-name could be omitted for protocols such as ADS where the
> address
> > already defines the type.
> > In that case we should probably also have API types for accessing these
> > parts of the addresses.
> >
> > What do you think?
> >
> > Chris
> >
> >
> >
> >
> > And for STRING and WSTRING to also have optional string-lengths in round
> > brackets behind the STRING or WSTRING.
> >
> > What do you think?
> >
> > Chris
> >
>

Re: [DISCUSS] Streamline the address format over all drivers

[Jinlin Hong <my...@gmail.com>]

Thank you for your reply, and my apologies for mixing up the bit and array
discussions.
Regarding the array syntax, I think it’s great to allow users to customize
the return format. That said, [5] and [4][6] do indeed represent the same
thing, haha.

Jinlin

Christofer Dutz <ch...@c-ware.de> 於 2025年2月6日 週四 下午3:19寫道：

> Replying to both in one email here.
>
> Regarding the array notation:
> I am proposing to use one format. So if you have a tag and ask it to
> return the string representation, you'll only get one format.
>
> I'm more proposing to make the parser a bit more flexible and support more
> options as input to allow some OT engineering addresses parsable without
> having to reformat all addresses.
>
>
> I think the bit stuff is a completely different discussion. Happy to do
> this in parallel... Let's stick to arrays in this discussion ;-)
>
> Chris
>
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Jinlin Hong <my...@gmail.com>
> Sent: Thursday, February 6, 2025 2:50:34 AM
> To: dev@plc4x.apache.org <de...@plc4x.apache.org>
> Subject: Re: [DISCUSS] Streamline the address format over all drivers
>
> We have previously discussed this, and some of the conclusions might no
> longer apply: Cleanup of how we handle all the bit-related fields
> <
> https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields
> >.
> In my opinion, regardless of the final rules, we just need to finalize it.
>
> Christofer Dutz <ch...@c-ware.de> 於 2025年2月5日 週三 下午2:27寫道：
>
> > Hi all
> >
> > I’m playing a bit with my UI thingy and am currently implementing some
> Tag
> > editor.
> >
> > I have inputs for the address string, the type name as well as the
> > array-info and I need to generate the full address string for all drivers
> > from these fragments.
> >
> > Currently it seems not all drivers follow the same structure.
> >
> > I did a survey on LinkedIn on the various aspects of how array-notations
> > could be processed.
> >
> > Even if the survey is not over yet, it does look as if the following
> seems
> > to align with most people:
> >
> > [2..5] implicates elements 2,3,4,5
> > [2..5, 6..9] is a multi-dimensional array
> >
> > Ideally, we should probably also understand things like, but when
> > serializing we should use above notations:
> >
> > [5] is a shorthand for elements 0, 1, 2, 3, 4
> > [4][6] (A more IT-like array definition)
> >
> > Now for integrating things in other tools, I think it would be good if
> all
> > address strings had the following structure (similar to how our
> connection
> > strings work)
> >
> > {protocol-dependent-address}:{typename}{[array-syntax]}{options}
> >
> > The type-name could be omitted for protocols such as ADS where the
> address
> > already defines the type.
> > In that case we should probably also have API types for accessing these
> > parts of the addresses.
> >
> > What do you think?
> >
> > Chris
> >
> >
> >
> >
> > And for STRING and WSTRING to also have optional string-lengths in round
> > brackets behind the STRING or WSTRING.
> >
> > What do you think?
> >
> > Chris
> >
>

Re: [DISCUSS] Streamline the address format over all drivers

[Christofer Dutz <ch...@c-ware.de>]

Replying to both in one email here.

Regarding the array notation:
I am proposing to use one format. So if you have a tag and ask it to return the string representation, you'll only get one format.

I'm more proposing to make the parser a bit more flexible and support more options as input to allow some OT engineering addresses parsable without having to reformat all addresses.


I think the bit stuff is a completely different discussion. Happy to do this in parallel... Let's stick to arrays in this discussion ;-)

Chris


Gesendet von Outlook f��r Android<https://aka.ms/AAb9ysg>
________________________________
From: Jinlin Hong <my...@gmail.com>
Sent: Thursday, February 6, 2025 2:50:34 AM
To: dev@plc4x.apache.org <de...@plc4x.apache.org>
Subject: Re: [DISCUSS] Streamline the address format over all drivers

We have previously discussed this, and some of the conclusions might no
longer apply: Cleanup of how we handle all the bit-related fields
<https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields>.
In my opinion, regardless of the final rules, we just need to finalize it.

Christofer Dutz <ch...@c-ware.de> � 2025��2��5�� �L�� ����2:27������

> Hi all
>
> I��m playing a bit with my UI thingy and am currently implementing some Tag
> editor.
>
> I have inputs for the address string, the type name as well as the
> array-info and I need to generate the full address string for all drivers
> from these fragments.
>
> Currently it seems not all drivers follow the same structure.
>
> I did a survey on LinkedIn on the various aspects of how array-notations
> could be processed.
>
> Even if the survey is not over yet, it does look as if the following seems
> to align with most people:
>
> [2..5] implicates elements 2,3,4,5
> [2..5, 6..9] is a multi-dimensional array
>
> Ideally, we should probably also understand things like, but when
> serializing we should use above notations:
>
> [5] is a shorthand for elements 0, 1, 2, 3, 4
> [4][6] (A more IT-like array definition)
>
> Now for integrating things in other tools, I think it would be good if all
> address strings had the following structure (similar to how our connection
> strings work)
>
> {protocol-dependent-address}:{typename}{[array-syntax]}{options}
>
> The type-name could be omitted for protocols such as ADS where the address
> already defines the type.
> In that case we should probably also have API types for accessing these
> parts of the addresses.
>
> What do you think?
>
> Chris
>
>
>
>
> And for STRING and WSTRING to also have optional string-lengths in round
> brackets behind the STRING or WSTRING.
>
> What do you think?
>
> Chris
>

Re: [DISCUSS] Streamline the address format over all drivers

[Jinlin Hong <my...@gmail.com>]

We have previously discussed this, and some of the conclusions might no
longer apply: Cleanup of how we handle all the bit-related fields
<https://cwiki.apache.org/confluence/display/PLC4X/Cleanup+of+how+we+handle+all+the+bit-related+fields>.
In my opinion, regardless of the final rules, we just need to finalize it.

Christofer Dutz <ch...@c-ware.de> 於 2025年2月5日 週三 下午2:27寫道：

> Hi all
>
> I’m playing a bit with my UI thingy and am currently implementing some Tag
> editor.
>
> I have inputs for the address string, the type name as well as the
> array-info and I need to generate the full address string for all drivers
> from these fragments.
>
> Currently it seems not all drivers follow the same structure.
>
> I did a survey on LinkedIn on the various aspects of how array-notations
> could be processed.
>
> Even if the survey is not over yet, it does look as if the following seems
> to align with most people:
>
> [2..5] implicates elements 2,3,4,5
> [2..5, 6..9] is a multi-dimensional array
>
> Ideally, we should probably also understand things like, but when
> serializing we should use above notations:
>
> [5] is a shorthand for elements 0, 1, 2, 3, 4
> [4][6] (A more IT-like array definition)
>
> Now for integrating things in other tools, I think it would be good if all
> address strings had the following structure (similar to how our connection
> strings work)
>
> {protocol-dependent-address}:{typename}{[array-syntax]}{options}
>
> The type-name could be omitted for protocols such as ADS where the address
> already defines the type.
> In that case we should probably also have API types for accessing these
> parts of the addresses.
>
> What do you think?
>
> Chris
>
>
>
>
> And for STRING and WSTRING to also have optional string-lengths in round
> brackets behind the STRING or WSTRING.
>
> What do you think?
>
> Chris
>

Re: [DISCUSS] Streamline the address format over all drivers

[Andoni Angulo <an...@zylk.net.INVALID>]

Hi Chris,

I’d like to share my thoughts on the array syntax. I agree with the survey results; I think they are the clearest options. However, in my humble opinion, there should be one—and preferably only one—obvious way to do it (paraphrasing The Zen of Python). Having multiple equivalent syntax options (the result of adding [5] and [4][6], in your example) could lead to confusion and ambiguity. I’d prefer to keep it as simple as possible.

Please let me know if I’ve misunderstood anything.

Kind regards,
Andoni