Cart
[Home] [By Thread] [By Date] [Recent Entries]
-----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-----
|
