67 lines
2.0 KiB
Plaintext
67 lines
2.0 KiB
Plaintext
|
head 1.3;
|
||
|
|
access;
|
||
|
|
symbols;
|
||
|
|
locks; strict;
|
||
|
|
comment @# @;
|
||
|
|
|
||
|
|
|
||
|
|
1.3
|
||
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.2;
|
||
|
|
|
||
|
|
1.2
|
||
|
|
date 2005.03.10.11.58.01; author BobMorris; state Exp;
|
||
|
|
branches;
|
||
|
|
next 1.1;
|
||
|
|
|
||
|
|
1.1
|
||
|
|
date 2005.03.10.06.05.32; author BobMorris; state Exp;
|
||
|
|
branches;
|
||
|
|
next ;
|
||
|
|
|
||
|
|
|
||
|
|
desc
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.3
|
||
|
|
log
|
||
|
|
@Added topic name via script
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@---+!! %TOPIC%
|
||
|
|
|
||
|
|
%META:TOPICINFO{author="BobMorris" date="1110455881" format="1.0" version="1.2"}%
|
||
|
|
%META:TOPICPARENT{name="BestPractices"}%
|
||
|
|
Due to one or another weakness of any particular schema language, some desired constraints are merely left to be expressed in annotation. In a complex schema it can be hard to notice these when developing code against the schema. There should always be a detailed and comprehensive document which collects all these expectations in a single place so that application writers have a guide to the "secret" constraints in the schema. An example of this might be logical relationships on the values of enumeration which are clear to humans from the names of those values, but are meaningless for machine processing if not enshrined in the business logic of applications and support libraries. Thus, if an enumeration contains the text "is bigger than", the document might express that it is expected that for no X and Y should it ever be the case that X is bigger than Y and Y is bigger than X and warn that the schema contraint mechanism (e.g. validating parse for XML Schema) will not signal this as an error.
|
||
|
|
|
||
|
|
Ideally, there should be an infrastructure that supports the development of tool suites that can be used by developers to embed in their applications and which permits the specification and implementation of modules or services that correctly indicate compliance with each of the "secret" constraints.
|
||
|
|
|
||
|
|
|
||
|
|
-- Main.BobMorris - 10 Mar 2005
|
||
|
|
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.2
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 2
|
||
|
|
@
|
||
|
|
|
||
|
|
|
||
|
|
1.1
|
||
|
|
log
|
||
|
|
@none
|
||
|
|
@
|
||
|
|
text
|
||
|
|
@d1 1
|
||
|
|
a1 1
|
||
|
|
%META:TOPICINFO{author="BobMorris" date="1110434732" format="1.0" version="1.1"}%
|
||
|
|
d5 2
|
||
|
|
@
|