[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Visiting your cake and eating it too (was StupidQuestion)

• To: xml-dev <xml-dev@l...>
• Subject: Re: Visiting your cake and eating it too (was StupidQuestion)
• From: Ronald Bourret <rpbourret@r...>
• Date: Wed, 06 Mar 2002 03:34:29 -0800
• References: <2X3W74B8GAHBN4Z63D8A6KFZIHHGNJ.3c855805@MChamp> <200203060138.g261ctu10329@d...> <3C85BA20.857FCE4D@r...> <001b01c1c4e1$2198c3f0$4bc8a8c0@A...> <5.1.0.14.2.20020306110803.02c1ae98@p...>

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
have been.)

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
given document.

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.

-- Ron

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.
> 
> Example:
> 
> 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
> involves
> 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 :-)

• References:
  • Re: Stupid Question (was RE: XML doesn't deserveits "X".)
    • From: Mike Champion <mc@x...>
  • Re: Stupid Question (was RE: XML doesn't deserve its "X".)
    • From: Joe English <jenglish@f...>
  • Re: Stupid Question (was RE: XML doesn't deserve its "X".)
    • From: Ronald Bourret <rpbourret@r...>
  • Visiting your cake and eating it too (was Stupid Question)
    • From: "Rick Jelliffe" <ricko@a...>
  • Re: Visiting your cake and eating it too (was Stupid Question)
    • From: Sean McGrath <sean.mcgrath@p...>

• Prev by Date: Re: Visiting your cake and eating it too (was Stupid Question)
• Next by Date: RE: Stupid Question (was RE: XML doesn't deserve its "X".)
• Previous by thread: Re: Visiting your cake and eating it too (was Stupid Question)
• Next by thread: Re: Stupid Question (was RE: XML doesn't deserve its "X".)
• Index(es):
  • Date
  • Thread