[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> That's not that easy and there is nothing in the specs which
> helps to create the discipline required in the applications to
> make it smooth.
>
> Let's take a simple example... I have a text only element:
>
> <ns1:foo>This is a simple example.</ns1:foo>
>
> If I extend this example to include a semantic element to
> identify "simple" as an adjective:
>
> <ns1:foo>This is a <ns2:adj>simple</ns2:adj> example.</ns1:foo>
>
> I am changing a text leaf node into a mixed content including
> 2 text nodes separated by a child element and this will
> likely break 90+% of
> the existing applications.
Yes. But then you need to ask why 90% of the applications are being
written in a way that isn't sufficiently additive or data-directed.
To me the change you've made looks like short work and most of that
is in writing the tests. If it's taking a long time to make these
kind of changes, its time to start asking the developers hard
questions.
On the other hand if A expects B to send a single node here, and
this has been contracted into the requirements somewhere, maybe as
a schema or DTD if you're lucky, then when B starts sending
something other it's in violation of that requirement/contract. You
might reasonably ask then what on earth possessed anyone to write a
requirement like that. Because if you're using XML you've foreseen
a need for change, right? Or why didn't someone 'require' that out
of band changes be mutually consented to? Or why didn't anyone just
plain understand that data and code go hand in hand?
To respond to the first paragraph above. You don't need paternal
specifications to protect your applications from change. You need
better developers.
Bill de hÓra
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPITr8OaWiFwg2CH4EQJoygCg4918TxC1kVgxWNqbzi2ys5TXo3cAn38g
fFC5PMHyQsiQPIvvz/DomHo9
=pTWT
-----END PGP SIGNATURE-----
|
