...
# | Questions/Open Issues | Notes | Decisions | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | What kind of naming validation should be in place? |
Alternate approach, exclude characters:
PLease note this does allow the following special characters
| Exclude characters:
PLease note this does allow the following special characters
| |||||||||||||||
2 | Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict. | As part of this commit, we can modify the code so anchor creation will happen for the cm handle registration. So if it fails the validation at this point, the CM-Handle will not be registered. | CM-Handle will follow same rules. when to validate is impl. detailed | |||||||||||||||
3 | Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? | Not recommended as this will add little value, at a high cost | Prefer to validate query/get input | |||||||||||||||
4 | Should dashes be included? | A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these. | Yes, see above | |||||||||||||||
5 | Implementation approach for validation | We have discussed 3 possible libraries for implementing this validation. These include java's util library, spring validator at the service level of CPS, along with using open api's 'keyword' for dealing with CM-Handle ID validation, or using apache commons validation regex library. | Have decided to use basic java util package. | |||||||||||||||
6 | The validation logic with the regex should be implemented in a separate utility class. | A new common utility class should be created specifically for regex validation as part of this user story. | Have decided to not use to use a separate class for this right now |
...