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 <myhongjin...@gmail.com> Sent: Thursday, February 6, 2025 2:50:34 AM To: dev@plc4x.apache.org <dev@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 <christofer.d...@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 >
