Lists Home |
Date Index |
I never meant to imply that the functions were optional -- just that
they were separate. In the case of XML Schemas, it would have been nice
if validation, adding data values (defaults, etc.), and augmenting the
infoset with type information were all separate operations. (If you
want, think of it as three different specs, which it probably should
That would allow me to write separate modules to perform each one.
Rick's point (with which I agree) is that these could all be executed in
a single pass. The only thing that is optional here is that the user
could decide which operations they want to perform when processing a
Note that because XML Schemas is written in a monolithic manner it is
not possible to perform these operations separately in an interoperable
way. That is, I could write modules to perform each operation, but there
is no guarantee that my code could be replaced by somebody else's code.
This is because we might each come to different conclusions about what
parts of the XML Schemas spec fits into each bucket.
Sean McGrath wrote:
> At 01:30 06/03/2002 -0800, Ronald Bourret wrote:
> >One consequence of the specs not bringing this out is that the software
> >implementing those specs is likely not to separate the functions either.
> >That is, it is completely reasonable to put all three (or more)
> >functions in the same piece of software and let the user decide what
> >they want.
> This approach leads to interoperability nightmares.
> Three functions A, B, C provided by systems S1 and S2 that are compliant
> with standard X.
> If support for A, B and C are optional, the interoperability of S1<->S2
> dealing with 3*3 = 9 functionality combinations.
> This is made worse by the fact that commercial software vendors will go out
> of their way to make it difficult to perform like with like comparisons by
> blurring the borders between features A, B and C.
> Specs that include "optional" behavior don't help either :-)