Hi,
Validation is often a multistep process. In most cases it is better to detect obvious failures early on in the process. The most common cause of error is data entry. Data entry errors can be avoided in the UI code. The basic validation rules in the catalog roughly match the standard HTML Form capabilities.
One of the most significant features of modern form controls is the ability to validate most user data without relying on JavaScript. This is done by using validation attributes on form elements.
required
: Specifies whether a form field needs to be filled in before the form can be submitted.
minlength
and maxlength
: Specifies the minimum and maximum length of textual data (strings).
min
and max
: Specifies the minimum and maximum values of numerical input types.
type
: Specifies whether the data needs to be a number, an email address, or some other specific preset type.
pattern
: Specifies a regular expression that defines a pattern the entered data needs to follow.
If the data entered in a form field follows all of the rules specified by the above attributes, it is considered valid. If not, it is considered invalid and will not be submitted to the server. This type of validation is called syntax validation.
Patterns are used to define the syntax of structured data (MAC-Address, IP-Address, BIC-Code, E.164 Phone number, ...)
The policy defines much more complex rules that can typically not be detected in the UI because they require lookups in inventories or other complex operations:
- E.164 Number must be on-net (including ported numbers)
- BIC-Code must be of a bank not sanctioned by the government
- The IP-Address must be geocode into a country
To summarise the regex, range, ... UI validation rules and the (buiness) policy rules serve a different purpose. It would be a mistake to remove first type of rules because the second type is introduced.
------------------------------
Koen Peeters
OryxGateway
------------------------------
Original Message:
Sent: Dec 21, 2022 09:27
From: David Xie
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Hi Jonathan,
There is regex
in SpecChar:
regex
A string. A rule or principle represented in regular expression used to derive the value of a characteristic value.
Will it be deprecated after introducing policyRef or constrainRef in SpecChar?
Regards,
------------------------------
David Xie
Hansen Technologies
Original Message:
Sent: Dec 19, 2022 09:41
From: David Xie
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Thanks Opher, valueSchemaLocation could be a solution for some type of validation rule. But it is difficult to change, import and export.
Thanks Jonathan for your response. I totally understand that. As API, it has to be simple and generic from implements.
Sorry to be troublesome, I have one more thinking regards the constrain change.
Is it possible:
1) Service/Char Spec has list of plicy or constrain
2) If policy doesn't has href, it is a value, which is for non-reusable rule
Of cause, there will be Spec regarding the value. But not go there now.
3) if policy has href, then it is a reference to policy in external domain or reusable rule.
------------------------------
David Xie
Hansen Technologies
Original Message:
Sent: Dec 19, 2022 05:15
From: Opher Yaron
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Thank you, @Jonathan Goldberg.
I absolutely agree with you as for business rules.
I was more thinking of the technical rules that David was talking about, both reusable and non-reusable. What do you think about using valueSchemaLocation for them?
Best regards,
------------------------------
Opher Yaron
Proximus SA
Original Message:
Sent: Dec 19, 2022 05:02
From: Jonathan Goldberg
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Opher, I don't think that the valueSchemaLocation is relevant for business rules
I'll open a JIRA issue for the characteristic spec enhancement, but I don't think any discussion of this will happen in the next two weeks due to the holiday season.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Dec 19, 2022 03:10
From: Opher Yaron
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Hi Jonathan, David,
I second the idea of adding policy rules in CharacteristicSpecification. I have the same need in ProcessFlowSpecification / TaskFlowSpecification.
At the time being, as policy rules are not yet supported (also in beta release 22.0.0), we are considering to use the "@valueSchemaLocation" attribute for this purpose.
@Jonathan Goldberg - I am curious what you think about this idea.
Best regards,
------------------------------
Opher Yaron
Proximus SA
Original Message:
Sent: Dec 16, 2022 08:21
From: Jonathan Goldberg
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Hi David
In v4 of the APIs, ConstraintRef is what you are looking for, but it is an opaque reference since we don't have a model or API for Constraint.
In v5, we plan to introduce a Policy authoring API, and to deprecate ConstraintRef in favor of PolicyRef. We now need to decide where to introduce PolicyRef in the P/S/R/E catalog entities.
Your feedback is useful, CharSpec would be a possible location to add policy rules.
Thanks
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Dec 15, 2022 17:07
From: David Xie
Subject: service validation and characteristic value validation rule in Service Catalog (TMF633)
Hello,
I am implementing TMF633 API for an existing service catalog.
In existing service definition, there are service validation rules, and characteristic value validation rules.
And there are different type of rules,
Simple rule, for example service exclusion rule, is defined with type and scope.
Complicated rule includes script (which returns back boolean during evaluation).
How to present those validation rules in TMF633 Service Specification model?
TMF633 ServiceSpecification has ConstrainRef. Is this the one should be used for service validation rule?
If yes, CharacteristicSpecification doesn't contains ConstrainRef, where should characteristic value validation rules go?
Thanks
David Xie
------------------------------
David Xie
Hansen Technologies
------------------------------