OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: CVA: multiple messages per context


Dear TC,

 

I wish to put forward a suggestion for improving the CVA draft:

 

Currently, a CVA context has one optional message. Whenever an error is triggered, a single message is returned to the processing application. However, there are different types of error messages, requiring different actions by the application:

-          Some errors need to be displayed to the user. Useful, when the user can rectify the error. (i.e. User message: “Currency Code is invalid. Select a valid code for client ‘123’.”)

-          Other errors cannot be rectified by the user, and require software vendor intervention. (i.e User message: “System error 3456. Please contact your software vendor.” / Detailed technical message: “Invalid instance-level meta data: The ‘version’ instance-level meta data for CurrencyCode is invalid for client ‘123’. ”

 

I suggest supporting  a distinction in multiple messages for a context.  Where at user option the CVA file can specify one error message when end-user specified instance-level metadata does not match any of the CVA-specified list-level metadata, and another error message (the default when no distinction is made) when there is no violation of instance-level metadata but a violation of the value itself in combination with the supplied instance-level metadata.

 

Perhaps one should even allow an arbitrary number of <Message> elements with a type= attribute, but no defined semantics by the specification.  Then an implementation can document the kinds of tests (two, three, any number) it does with CVA files and offer users to specify type= for the particular kind of error supported by the implementation. .

 

I’m keen to hear whether  other CVA users have a similar requirement?

 

Regards,

 

Juerg Tschumperlin

Data Management Solutions

Wellington, New Zealand

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]