Hi All, thanks for that. And just an update … I’m already working hard on this on my refactoring banch. Reason was, that I only wanted to break SNAPSHOT once for anyone that might be relying on it.
Chris From: Xiangdong Huang <[email protected]> Date: Wednesday, 9. November 2022 at 05:11 To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Rename Fields -> Tags? +1 for Tag. Just want to share that I researched many historian systems (include OSIsoft PI, Siemens WinCC, Emerson DeltaV, etc.), all of them are using "Tag". ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Otto Fowler <[email protected]> 于2022年11月9日周三 11:41写道： > > +1 > > From: Ben Hutcheson <[email protected]> <[email protected]> > Reply: [email protected] <[email protected]> <[email protected]> > Date: November 8, 2022 at 15:20:51 > To: [email protected] <[email protected]> <[email protected]> > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > +1, while I don't have your commitment to go around and change it. I think > it makes it better aligned with OT nomenclature. > > On Tue, Nov 8, 2022 at 2:21 AM Christofer Dutz <[email protected]> > wrote: > > > Hmmm … ok, > > > > So, I count two people for using Tag and sort of Two for using Field. > > Am I correct with this? > > > > At least my LinkedIn question seems to be clear that most people would be > > expecting “Tag”. > > And I mean … I think we don’t need to work on having PLC4X accepted on > the > > IT side, but on the OT side. > > Making it more aligned with what the OT folks expect seems to be a better > > path for me. > > > > But I would really appreciate a bit more clear outcome of this > discussion… > > so anyone who’s not posted his opinion yet is highly encouraged to do so. > > > > I’d just hate to rename something like that after a 1.0.0. > > > > Chris > > > > > > > > From: jl hong <[email protected]> > > Date: Tuesday, 8. November 2022 at 02:56 > > To: [email protected] <[email protected]> > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > Hello Chris, > > I had the same confusion with Łukasz about what "Tag" meant when I first > > met it in using Rockwell > > PLCs.Maybe it is more difficult to understand than "Field".Also, I think > > "Field" is not accurate enough too. > > Finally, I think either "Tag" or "Field" is acceptable, and people should > > both be able to understand it from the document or context. > > By the way, we call it "Point Position" in Chinese, I translated > directly. > > > > Christofer Dutz <[email protected]> 於 2022年11月8日 週二 凌晨4:49寫道： > > > > > Probably should rename „fieldQuery“ to „fieldAddress” (or tagAddress) > as > > I > > > split Fields and Queries as a query usually targets more than one > element > > > and an address normaly doesn’t. > > > > > > Chris > > > > > > From: Christofer Dutz <[email protected]> > > > Date: Monday, 7. November 2022 at 21:40 > > > To: [email protected] <[email protected]> > > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > > And regarding your points, Lukasz, > > > > > > The output from the Browse API is that it is a BrowseItem. This > contains > > a > > > Field (or Tag if we rename it) and loads of metadata. > > > Is the Field readable, writable, subscribable, loads of protocol > > dependent > > > options. > > > > > > The Field itself now should be able to produce an address string that > > > should be able to re-produce it. The APIs all support “addFieldQuery” > > which > > > takes this string representation or “addField” which directly receives > > the > > > field object. > > > > > > Chris > > > > > > > > > From: Łukasz Dywicki <[email protected]> > > > Date: Monday, 7. November 2022 at 13:48 > > > To: [email protected] <[email protected]> > > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > > Hey Chris, > > > I do not insist on any side. Knowing how hard it is to get a "common > > > understanding" on certain things I think it is easier if we stick with > > > project specific concept. > > > > > > Other point, we do not need to re-use a PlcField and field notion > > > everywhere. For example output from browse api might be a descriptor > > > which can be used to construct a field address. After all, a browsing > > > functionality might provide more information than needed to fetch data > - > > > ie. human readable name, description or other elements which are > > > irrelevant for driver to get data. > > > > > > As a side note, I do acknowledge that best time to do naming and larger > > > API alignments is prior 1.x release. > > > > > > Best, > > > Łukasz > > > > > > On 6.11.2022 13:32, Christofer Dutz wrote: > > > > Hi Lukasz, > > > > > > > > even in protocols like ADS and EIP at Rivian everyone is referring to > > > any data point as a “Tag”. > > > > So far, I haven’t come across a single person saying something else > on > > > LinkedIn. > > > > > > https://www.linkedin.com/feed/update/urn:li:activity:6994584721582088192 > > > > > > > > And keep in mind: PLC4X is meant to be the bridge between IT and OT, > > and > > > we chose a lot of stuff (Like the address patterns, etc.) to match the > OT > > > expectations. After all, I will most probably be an IT person asking > the > > OT > > > person: Please give me the address for Field/Tag XYZ. So, I think > naming > > it > > > “Tag” would be better. > > > > > > > > I would like to name it to match the most used term: I know that this > > > isn’t always a perfect match in all protocols, but I guess that’s the > > > difference between providing a “shared API” or building individual > > drivers > > > for each protocol. > > > > > > > > And currently we name it “Query” in Go … so you currently say: > > > “AddQuery” instead of “AddField”. > > > > > > > > Chris > > > > > > > > > > > > From: Łukasz Dywicki <[email protected]> > > > > Date: Sunday, 6. November 2022 at 11:45 > > > > To: [email protected] <[email protected]>, Christofer Dutz < > > > [email protected]> > > > > Subject: Re: [DISCUSS] Rename Fields -> Tags? > > > > Hey Chris, > > > > I am not certain if "tag" is standardized or not. Earlier, knowing > only > > > > modbus registers and bacnet objects, I been confused multiple times > > what > > > > the tag is. For regular IT tag is rather a marker placed on something > > to > > > > categorize elements. Our field currently specifies rather a unique > data > > > > point than a tag. > > > > If tag meaning comes from IEC standard then I'd opt in for a change. > If > > > > its not standardized then I'd advice staying with a field. Our use is > > > > mixed IT/OT (with probably still more IT?), if we stick too much to > > > > automation industry terminology then we will need to bake definition > of > > > > a tag, fight situations where we miss a "common understanding" cause > we > > > > can't beg others for unification of their meaning. > > > > > > > > I've seen tag used in context of ethernet/ip (more precisely Rockwell > > > > PLCs), but haven't done a research of why. Keep in mind we have also > > > > object oriented protocols such as BACnet (with > > `device.object.property`) > > > > and CANopen (with `device.sdo` or `device.tpdo..`) thus in their > > context > > > > tag is far less meaningful than field. > > > > > > > > Cheers, > > > > Łukasz > > > > > > > > On 5.11.2022 12:23, Christofer Dutz wrote: > > > >> Hi all, > > > >> > > > >> I’m currently working on harmonizing our different API variants a > bit > > > and hopefully finalizing our Browse API (Which sort of wen’t through > > > multiple levels of change between Java and Go, back to Java and now > back > > to > > > Go. > > > >> > > > >> One thing I learned at Rivian is, that everyone seems to be talking > > > about “Tags” on PLCs. So I asked on LinkedIn and it seems pretty > obvious > > > that “Tag” seems to be the term mostly used in the automation industry. > > > >> > > > >> So, I would like to consequently rename “Field” to “Tag”. > > > >> > > > >> What do you folks think? > > > >> > > > >> Chris > > > >> > > > > > > > > >
