[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Need a language whiz: An XML Schema "specifies" how data i

  • From: "Frank Steimke" <f-steimke@berger-und-steimke.de>
  • To: <xml-dev@lists.xml.org>
  • Date: Fri, 5 Jan 2018 07:28:27 +0100

Re:  Need a language whiz: An XML Schema "specifies" how data i
and thank you all for your comments and hints. They are indeed very helpful.

I totally agree that validation and assessment is only half the story. We can think of many reasons why we have to reject a document eventually, although it has passed the validation and assessment phases. Maybe we could think of more than one assessment phases. Some of them can only take place within the communication endpoint, they are not limited to Schema technique and may use additional resources from this endpoint (e. g. databases). This kind of assessment may tend to be more like an expert system, as Rick said.

The assessment we have in mind is only based on the exchanged document structure and content that has to be checked against rules that can be expressed within Schema language. It is not an expert system. It can be done anywhere between communication endpoints, since it does not rely on addition resources. It is especially suitable in the four corner model (e. g. PEPPOL), located at the transport layer.

We have learned from Mikes post that XSD specification uses the terms validation and assessment interchangeably, while we would like to distinguish them. One difference between these two terms is, that validation is independent from any of the involved parties, while assessment is not.

The result of validation must only depend on the instance and the Schemas (XSD an Schematron in this case). It shall objective and unambiguously tell whether I am obliged to accept the instance (since it is conformant to the agreed specification), or allowed to reject it (since it is not conformant). This may be a legal issue. That’s why we would like to have binary outcome of validation:

validation(schema1, … schemaN, instance) => xs:boolean 

I am quite aware of the fact that the outcome validation engines, let it be XSD or Schematron, is a sequence of messages, some of them marked as error or warning. But there must be an objective, user-independent way to decide whether the document is valid with respect to the set of schema1 … schemaN or not. 

Assessment, on the other hand, may depend on users preferences. Some users are more relaxed than others. They will accept invalid instances, as long as there are only minor errors. Distinction between minor and severe error depends on user preferences and may change with time. Assessment is not a legal issue (I hope so). 

assess(schema1, … schemaN, instance, preferences) => outcome 

The outcome includes, but is not limited to, a recommendation whether to accept or reject the instance.

Do you think that this is a sound and consistent way to use these two terms ?


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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.