[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
AW: [xml-dev] Need a language whiz: An XML Schema "specifies" how data is to be structured? "describes"? "constrains"?
- From: "Frank Steimke" <f-steimke@berger-und-steimke.de>
- To: <xml-dev@lists.xml.org>
- Date: Thu, 4 Jan 2018 07:59:11 +0100
A remark to Mikes comment: we are dealing with the exchange of structured
messages between ict systems. The structure is coded in XML.. We use XML
Schema (XSD together with Schematron) as a language, which describes the
agreement of the involved parties about the messages to be exchanged. We can
make statements about the allowed structures (syntax) as well as (parts of)
the semantic of messages. A typical scenario is the exchange of electronic
invoices. Syntax and semantic can be defined in terms of UBL Schema and
additional interoperability specifications and business rules like european
EN 16931, which has a lot of schematron rules.
In this scenario, we try to distinguish between the words “validation” and
“assessment”. In fact, from our point of view, we see them as two distinct
phases on the receiver’s side.
Validation answers the question: does the exchanged document fulfil all
requirements of all involved Schemas? Validation should be a binary
decision: the message, which is an XML document, is valid to a Schema, or it
is not valid. We think that this is true for XML Schema (XSD), but we are
not sure if this is also true for Schematron Schema. Is a document with only
on failed-assertion, which @flag or @role is not error but warning, valid or
is it not valid? However, validation should be a clear and deterministic
yes-or-no decision, and this idea is supported in the definition of a
schematron processor in the ISO Standard for Schematron.
Assessment, on the other hand, is the second phase on the receiver’s side.
It means: decide whether you will accept or reject the message. This
decision is of course based on the result of validation. It should be easy
if there are no validation errors (you are obliged to accept), but in case
of validation errors, you are not always obliged to reject. Assessment
basically means: can we accept a message although it is not valid? Again,
this is especially important when the validation error is in fact a warning
in case of a Schematron business rule.
We have just discovered that the distinction between these two phases may be
useful, because it can give a lot more flexibility, especially when you try
to introduce new vocabularies for message exchange and you are not sure
about all the business rules. In fact, you can find a java application which
implements validation and assessment in Github at
https://github.com/itplr-kosit/validationtool
We are pretty much interested about comments from the experts, whether the
distinction between these two phrases (and phases) makes sense and seems to
be useful.
Thanks in advance,
Frank Steimke
-----Ursprüngliche Nachricht-----
Von: Michael Kay [mailto:mike@saxonica.com]
Gesendet: Mittwoch, 3. Januar 2018 17:25
An: bryan rasmussen <rasmussen.bryan@gmail.com>
Cc: Costello, Roger L. <costello@mitre.org>; xml-dev@lists.xml.org
Betreff: Re: [xml-dev] Need a language whiz: An XML Schema "specifies" how
data is to be structured? "describes"? "constrains"?
The essence of the semantics of XSD is that the specification defines a
process, variously called "validation" or "assessment", that takes a schema
and an instance document as input and produces an assessment outcome as its
result.
assess(schema, instance) => outcome
(It's slightly more complicated than that because you can specify other
inputs to the assessment, e.g. strict/lax).
The specification does not use any specific term (such as "describes" or
"constrains") for the relationship between a schema and the set of instance
documents for which assessment has an outcome labeled "valid". You're
perfectly welcome to use a term such as "describes" for this relationship if
you wish, but it's not a term-of-art in XSD itself; so if you use it, you
should say carefully what you mean by it.
Michael Kay
Saxonica
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]