This is the discussion topic for the wiki article: XNodes

Given that there are some differences for XNodes between versions (abilities get deprecated or even dissapear, other are new, descriptions and public names change), I would advise to distinguish between LabVIEW versions, so to have for example a Copy_(LV80_XNode_Ability) article and a Copy_(LV82_XNode_Ability) article, instead just one Copy_(XNode_Ability).

That way we could be prepared for the changes NI could be including right now in a hypothetical future LabVIEW release .

But of course, I don't know a word about wiki .

Saludos,
Aitor

In comparing XNodes between LabVIEW 8.0 and LabVIEW 8.20, it's clear they intend to keep backwards compatibility. This is indicated by this scenario:
Name | Public Name (in 8.20)
BuildPopUp | BuildMenu
BuildMenu | BuildMenu2
BuildMenu3 | BuildMenu3

(The first column is the actual Ability names, not the "pretty" names)
This is what NI did in this instance:
1) They made the Ability BuildPopUp for XNodes in 8.0.
2) They needed something more ("Help Info" cluster), so they made the function "BuildMenu" which was to replace the old "BuildPopUp" without stepping on the old Ability's toes. They also decided that the name "BuildMenu" was more appropriate to this Ability in general.
3) They needed something more ("ID" string), so they made "BuildMenu3". They could have made an Ability "BuildMenu2" but no such ability actually exists. This is because they decided to refer to the "first" item as (public name) "BuildMenu", which means that the (ability) "BuildMenu" is (public name) "BuildMenu2" and to move forward away from the not-so-aptly named previous Abilities (some taken from External Nodes).

This means that you don't have to worry about ever mixing up the names, as long as you always refer to the Ability names, and not the Public names.

Let's say in LabVIEW 8.21 there's a new Copy Ability...they forgot to add in some parameter that would really help. Three things could happen:
1) They decide the name is inappropriate (not likely, the public name is the same), and rename it to, say, ExecCopy.
1a) They might now refer to the "Copy" as "ExecCopy" and thus make the new Ability ExecCopy2.
1b) They might ignore the old copy name and make a new Ability ExecCopy. This results ultimately in what you see happened with "BuildMenu"...the next one after that would probably be ExecCopy3.
2) They decide the name is appropriate and increment the name: new Ability Copy2.

I'm afraid the "Bounds" function (public name GetBounds) will have future names: GetBounds2, GetBounds3...so no "GetBounds" Ability should ever exist.

Ultimately, there's never any overlap, so the Ability names will always be unique and refer to the proper Ability (Public Name doesn't mean anything other than intended name). Deprecation doesn't imply removal at this point.

Hopefully they also stop changing the friggin' names.

It's not so simple, Adam. I know the difference between public and actual name (hey, I put that in the documentation ), but there are more things to consider that can make useful to have a separate list for every version:

1) I'm afraid abilities can be removed. For example, LV8 accepts an MutateToXNode ability that has dissapeared in LV82. This could happen again (though I think it's not usual).

2) Public names can change. That happened from LV8 (where public names and private names were the same) to LV82, and I would bet this will happen again in future versions of LabVIEW .

3) The descriptions for the abilities change from one version to another. Supposedly, later descriptions are more accurate than previous ones, but I prefer to have the original description for each version (though is debatable).

4) And more important, what if somebody wants to develop a XNode in LV8? He goes to the wiki and see that ListErrors is deprecated... but it's not deprecated in LV8, and in fact is the only ability he can use, since ListErrors2 and GetErrors3 are not supported in that version.

Anyway, that was just my two cents .

Saludos,
Aitor

This post has been edited by Aitor Solar: Mar 16 2007, 08:56 AM

Although it has disappeared, it probably still works in LV8.20...not that I've seen it or seen it work in the first place, it looks a bit similar to ReplaceSelf, which appeared in LabVIEW 8.0. Do you have more information on this Ability? I can see the base construct in LV8 as you suggest, but I haven't seen it implemented. It's possible this was forcefully deprecated (and maybe still existent) because it did something very...buggy or something like that. The AugmentSelf and ReplaceSelf Abilities (new to LV8.20) might be the "heirs."



And this is why Public names don't really mean anything but the "intended" name. They can't go back and change the name of old Abilities, but they can change the Public name to reflect how they wish they had named it originally. The older "Public Names" can easily be incorporated into the Ability articles.



I haven't compared the descriptions between the versions yet (I am planning on including the older descriptions for each one also, if different), are there any changes that you've noticed that mark a difference in behavior? I think you're right in that the "latest" description is usually more accurate (after they've used the "newest" abilities). The older descriptions will be incorporated into the articles as well.



And this is definitely your best point. I'm in the process of incorporating such details as "introduced in labview 8.xx" and "deprecated in labview 8.xx". I have the lists from LV8 and LV8.20 and I'm going to make sure LV8 isn't left in the dust.

Keeping the information for LabVIEW 8.0 XNodes is definitely going to happen. I think that the Abilities are similar enough to warrant keeping from having to name each ability with its introduced version number, and if there is any discrepancy then a simple "Description in LabVIEW 8.0" (each version that differs) section in the Ability articles will be present (or maybe "Description in LabVIEW 8.20" for the current descriptions to start), along with "Public Name in LabVIEW 8.0" and any other miscellaneous information we come up with regarding these things.



Golden pennies indeed...don't worry, things have just started to warm up and I'm pretty picky about wiki formatting (in a good way). I'm going to ensure that everything anyone's found out about XNodes in any version will ultimately be in the documentation. Step one was porting the detailed document you and Dany Allard made. Step two is making sure it's in there in a way that large changes won't have to happen later. Step three is adding all the extra information, and then finding more information to put in there.


- Adam

I think we should stick to singular form in the page titles i.e. I think the page title should be XNode rather than XNodes.

I agree.

I remember that you made a policy about this, and saw that you moved some things around.
I prefer the singular case as well

Ton

Yes, that's right:

Manual_of_Style - Prefer_singular_nouns