[
Lists Home |
Date Index |
Thread Index
]
> Due to the way we write programs to process XML data, we weave a set of
> implicit patterns or schemas within our code, which resembles closely to the
> explicit schema of the XML data (that is, if there is such a schema). BTW,
> by schema I mean of course any kind of structural constraint on the
> document, not specifically schemas written in XML Schema.
>
> As soon as the explicit schema is changed, there is a mismatch with the
> implicit schema woven in the code, and the result is the code is broken.
This is a problem that Architectural Forms solves (perhaps THE problem).
Rather than making the schema implicit in your code, you make it an
Architectural Form. Once this is externalised, then changes to the actual schema
used by the data can be mapped back to the Architectural Form your application
has been developed to process.
You can view an Architectural Form as a definition of the input criteria for an
application. If the data conforms to this format, or can be mapped to that format,
then it can be processed by the application.
Having a schema to validate the Architectural Form simply allows you to test the input
criteria, i.e. the pre-conditions for successful completion of that application. This is
the power of Architectural Forms.
The data formats can evolve separately to the code -- not indefinitely, because
presumably there is additional value being added to the data with the additional
markup. But application evolution becomes a local process and doesn't have to be globally
co-ordinated or agreed.
Later in this thread, Eric suggested the addition of something like this to
W3C XSD:
<xs:any namespace="##other" processContents="skip"
foo:process="remove|value-of|copy-of"/>
This looks a lot like AFs to me.
L.
--
Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic | sine necessitate"
http://www.xml.com/pub/xmldeviant | -- William of Ockham
|
