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 <christofer.d...@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
>
