Cart
[Home] [By Thread] [By Date] [Recent Entries]
Ghost? Boo! I have four other angles:4) Length of the workflow. If data is going from A-B, there is less reason for a schema. If data is going from A to B to C to A to D to E to F to B to G, then you start to have big coordination costs. And opportunities for errors made early not to be caught till late: a fatal flaw in many cases. The schema is the contract and documentation. Where I am closer to Simon's view than perhaps others may be, is that when we look at the above 4 motivating cases for using schemas, then very often we do have some known process involved. So in fact static tests of the input and output documents are necessary but not sufficient: we need to check the input or output document against facts in the outside world that may be controlled by others or be dynamic (e.g., code lists) and we may need to check that transformations have indeed preserved information (e.g. if there are 5 paras in the input there should be 5 equivalent paras in the output). We need to make sure we don't use specific schemas where generic ones are more appropriate (e.g. simpler schemas with attribute values checked by other layers of validation, or partial schemas for envelopes and payloads) and that we have enough capability to convert generic to specific when tools require it.. This is where Schematron's approach (but not DTD, XML Schemas 1.1, RELAXING, and Examplotron miss out. I don't know about CAM here) shines. A little bit of TDD/QA/Conway/cost-reduction goes a long way, but a little bit is all the grammar-based schema languages provide. Where I would disagree with Simon, I think, is that I think the advent of JSON for point-to-point interchange actually means that probably you should always use a schema with XML: if you don't need a schema perhaps you should be using JSON? Actually, that is too much: what trumps often is how easy a format is to fit into your current ecosystem and capabilities: if you are sending data from an OO servlet to JavaScript, maybe JSON will fit best even if you have TDD and QA etc issues. But if you already have XML ecosystem and capabilities, then maybe XML Schema is the best choice even if JSON would be terser. Cheers Rick Jelliffe On Wed, Apr 10, 2013 at 12:36 PM, Len Bullard <cbullard@h...> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
