Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NXtransformations validation problems #430

Closed
mkoennecke opened this issue Jan 11, 2016 · 3 comments
Closed

NXtransformations validation problems #430

mkoennecke opened this issue Jan 11, 2016 · 3 comments
Labels

Comments

@mkoennecke
Copy link
Contributor

The NXDL for NXtransformations is IMHO wrong:

  1. The required content of NXtransformations is a depends_on NX_CHAR field. This is not there.
  2. Then there is a template for an anonymous field with the CIF attributes in there. IMHO, this is
    purely documentation. While, most fields involved in transformation should be in NXtransformations,
    the depends_on chain can also point out of the NXtransformations group.

I want this to be seen and OK'ed before I fix this

@zjttoefs
Copy link
Contributor

  1. The NXtranformations group is a container for transformations. As such it has no defined origin of it's own. All transformations contained need to be valid individually and thus have a depends_on. So I have no idea what a depends_on in the NXtransformations would mean.
  2. Nothing is said about where the dependency chain points. There are no limits there. The specifications means to say that this group contains any number of transformations (ideally at least one though) without requiring certain naming. If that can be better expressed, that would be okay with me.

I guess we can close this after the next telco.

@zjttoefs zjttoefs added the telco label Jan 20, 2016
@zjttoefs zjttoefs changed the title NXtransformations is wrong NXtransformations validation problems Jan 20, 2016
@zjttoefs
Copy link
Contributor

The missing depends_on is correct, we agreed on in the telco.

The anonymous fields still pose a problem in the validation. There is a suggestion by Peter Chang for a similar problem elsewhere that was accepted by Pete Jemian. I will dig that out in a minute.

@zjttoefs
Copy link
Contributor

zjttoefs commented Jan 20, 2016

It was actually exactly this case. We even have an issue already (now closed): #272
The name tag for what is thought to be a viable solution was accepted in pull request #411
Closing here (duplicate now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants