[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fwd: It is okay for things to break in the future!
One answer is to use a schema language with an ability to distinguish between the strengths or natures of different constraints. You need a schema language that helps you ask and specify, when you have some constraint, questions like WHY have that constraint, HOW should it be reported, and WHAT are the processing ramifications? If your schema language treats documents as existing outside the SDLC and where there is no separation of concerns between different constraints and their rationales, then over time, why would you expect not to be mugged by reality? For example, in Schematron,
<sch:rule context="book"> <sch:assert id="r1a1" test="count(author) =< 100" role="warning" diagnostic="as-of-2022" flag="non-2022" >A book is expected to have no more than 100 authors.</sch:assert> ... </sch:rule> ... <sch:diagnostics> <sch:diagnostic id="as-of-2021">This constraint is a processing capacity required for systems developed starting 2021; documents that do not meet this constraint may need special attention.</sch:diagnostic> <sch:diagnostic id="as-of-2022">This constraint is a processing capacity required for systems developed starting 2022; documents that do not meet this constraint may need special attention</sch:diagnostic> ... </sch:diagnostics> <sch:properties> <sch:property id="book-special-treatment"> <my:handle-specially type="book" /> <sch:span class="title"><sch:value-of select="@id"/></sch:span> </sch:property> </sch:properties> This would typically produce an SVRL (Schematron Validation Report Language) result like this: <svrl:failed-assert location="/book[1]" id="r1a1" test="count(book) =< 100" flag="non-2022" role="warning"> <svrl:text>A book is expected to have no more than 100 authors.</svrl:text> <svrl:diagnostic-reference id="as-of-2022"> <svrl:text>This constraint is a processing capacity required for systems developed starting 2022; documents that do not meet this constraint may need special attention</svrl:text> </svrl:diagnostic-reference> <svrl:property-reference id="book-special-treatment"> <my:handle-specially type="book"/> <svrl:text> <svrl:span class="title">NCD Risk Factor Collaboration</svrl:span> </svrl:text> </svrl:property-reference> </svrl:failed-assert> You can see that there is a separation of concerns allowing 1) The constraint information provided by SMEs to be expressed in a way that notional users can understand. (The constraint text.) 2) Extra metadata to be attached to say the severity or nature of that constraint (@role="warning") which can be used for triage, GUI, notifications and pipeline dispatch, 3) Information to categorize the whole document accordingly (@flag="non-2022") 4) Extra information to convey to humans (e.g. whoever is first inline to fix the issue) to explain why this is a problem (the text in the diagnostics element) 5) Extra information for subsequent handling systems to route and process this document (here, an element in a foreign namespace, and the title of the document) So we see that in this schema, there were also some constraints for system for 2021 and some for 2022: perhaps the number of authors was upgraded. It is possible to model this in Schematron using the phases mechanism: you could have all the patterns that are applicable for systems developed in 2022 which those systems can use to validate, and another for systems developed in 2021 which those systems can use to validate. (Or you could have a phase which lets you detect whether a document requires a 2021 or a 2022 system, and validate that first, then forward the document to the appropriate system or to triage.) Lets face it, it was common practise by the late 1970s to classify log messages by criteria (such as fatal, error, warning, info). Indeed it still is. But the grammar-based schemas do not provide any means to classify their constraints in useful ways: which means that they are only useful for the most rudimentary kinds of validation, for constraints that are likely true at all stages in the SDLC and document pipeline, and have equal significance. Consider this: some schema languages provide mechanisms for one schema to build on another in some way, but again they fail to provide simple annotations to convey to humans or systems why the change is needed or how it applies. To put it another way, constraints themselves need to be "typed" or, rather, support standard and ubiquitous metadata annotations that progress into the PSVI or equivalent (in Schematron, the PSVI is the SVRL linking into the original document(s) being validated in a session.) The particular scheme used for those values may be specific to the use-cases and schema, but the standard elements or attributes need to be first-class parts of the schema language. (Note also that the XPaths themselves are not adequate to express anything useful for humans and systems in the rest of the SDLC or document pipeline.) The problem of describing what goes in a single
instance of a document is, in a sense, trivial (e.g. a schema to allow
some objects to be serialized, transmitted, parsed and bound as objects
at the other end.) There is no time, no change, no gotchas, no intent, no systems, no humans. The problem of how to do software engineering with
documents, where your schema needs to fit into a dynamic, evolving,
multi-party, non-uniform web, is much more challenging, I think. And violently practical. I think those challenges demand first-class support in the schema language (and because the future is unpredictable, it may well demand an approach based on mix-ins rather than inheritance: I don't think that is too controversial to suggest...) I think Schematron shows that it is entirely practical to have systems that handle those challenges pretty well, and consequently entirely reasonable to require that schema languages should support them. Regards Rick On Tue, Aug 30, 2022 at 9:18 PM Roger L Costello <costello@mitre.org>D wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|