OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [provision] element ref won't work.



We should not be letting the tail wag the dog. The most important thing
is the SPML protocol itself, not the XSD. The XSD is merely a means to
document the protocol. The XSD is NOT the protocol.

We have decided as a committee that a batch request looks like:

<batchRequest>
  <addRequest>...</addRequest>
  <modifyRequest>...</modifyRequest>
</batchRequest>

This is simple, easy to describe, and easy to understand. This is how
SPML 1.0 worked and this is how SPML 2.0 should work as well, XSD issues
aside.

Under no circumstances will I agree to make the SPML protocol more
complicated just to satisfy "XSD Purity". That may seem like an extreme
position, but SPML has gotten complicated enough already. If we can't
make something work at all, that is one thing. But this is not the case.
Using the open content model with normative text is acceptable and
consistent with other parts of the SPML 2.0 spec.

Also, using xsi:type adds zero value to the solution. It still defers
definition of the requests to runtime, just like the open content model
does. This just is a more complicated way to express the exact same
information, with possible support issues thrown in just for fun.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]