Lists Home |
Date Index |
- From: "Simon St.Laurent" <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 18 Dec 2000 09:29:21 -0500
At 06:42 PM 12/18/00 +0800, ricko wrote:
>From: "Simon St.Laurent" <email@example.com>
>> I also liked the unit-testing approach, and it's something I've been
>> integrating more and more with own development. XML seems to have an
>> interesting relationship with this aspect, since well-formedness checking
>> and validation provide a couple of useful tools for testing certain
>> aspects of software.
>If the regression-tests must be prepared with the black-box unit, and if the
>turnaround time is so short, then using XP with XML seems to require the
>availablility of lightweight, simple XML testing languages.
I'd even go a bit further than XP and suggest that testing those aspects
should be done in as human-friendly a way as possible, since the
possibility of document interchange means that this aspect is likely to
need testing beyond the initial deployment, and that non-programmers are
more likely to get exposed to that black box.
Sounds like a job for Schematron!
>In the olden days, I was struck by the difference in attitude of people
>using DTDs and OmniMark, and people using DTDs that were compiled into
>applications. The OmniMark people had a very free approach to tinkering with
>the DTDs to perform checks, while the people using compiled-in DTDs never
>used DTDs as a way to check data. I think simple DTDs are pretty
>lightweight. Undoubtedly people who become familiar with XSDL will be able
>to use it for ad-hoc tests of particular structures, but I am not sure
>whether the power it provides in datatyping provides the kinds of checks
>that people need for testing in-progress XML documents.
I think this may be why I find the idea that schemas will be compiled into
parsers so depressing, though you've explained it far better than I have.
Flexible, lightweight, and ad hoc testing that can be modified over the
course of development to meet different needs seems like a wiser approach
to me than a straitjacket built at the inception of a project. Even if you
never change your data model, the mere possibility of doing so may open new
possibilities and encourage more flexible design.
>I think Schematron can fit in here. It has a simple syntax. It is "open" by
>default. It lets you test an output document based on an input document
>(i.e., black-box testing, not just static testing of output and input
Yep. I'd say it fits perfectly. I like the output/input connection, but I
think I like most of all that Schematron makes it relatively easy to add
and remove constraints.
There are plenty of cases where documents with the same overall schema
receive different processing, and other cases where documents with
different overall schemas but similar parts need to receive the same
processing. Schematron seems like a good way for developers to sort
through these kinds of cases, not least because of its openness.
>I was happy to see Kip Hampton's recent implementation of Schematron as a
>Perl function: I think it shows a good way to go. It can be invoked inside
>a program for testing preconditions/postconditions. What is particularly
>interesting is that one can add rules and assertions dynamically during the
>course of a program. So if at an early stage you know that the address is
>in New York, you can arrange for only the appropriate tests for American
>addresses to be loaded into the schema, allowing not just static testing
>(e.g. document tests) and end-to-end testing (e.g. blackbox tests) but also
>accumulated testing (e.g. whitebox tests).
Sounds like Schematron continues to evolve. I'll have to take a look at
this - that's even more flexibility, and sounds useful too!
Whatever happens in the Schemas arena (DTD XSDL RELAX XDR ETC), I expect
Schematron to have a long life expectancy.
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books