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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Non-schema approach to web service design: comments?

[ Lists Home | Date Index | Thread Index ]

I see how this would be vastly easier in Schematron, or another schema
language that allows co-occurrence constraints?  I should have
instantly thought of that as the most commonly discussed reason why
real-world format constraints can't be expressed in XSD.

Strictly speaking, Schematron is independent of / complementary to
XSD, however.  It seems like it would be easier to figure out how to
get them to work usefully together than start the schema wars over
again.


On 10/28/05, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> I suppose most of the real world needs are actually doable via schematron.
>
> Error Assertion Markup, I want to do a service where people send
> messages consisting of example xml instances with namespace qualified
> attributes in an Error Assertion namespace delineating what the
> expected errors are on a particular element, what leads them to assume
> that this is an error (documentation, schemas), if they have a
> particular processor they use and what the return of that processor is
> for that element etc. etc., identified 18 requirements. The example
> xml instances can be for any of the hundreds of namespaces we have
> under our control. I cannot think of any way to specify this in XML
> Schema (xsd:any with 18 possible attributes in the eam namespace?!? )
> Not to mention that the only part of the error assertion markup
> namespace where reasonable validation could be done would be the
> context between attributes, in situations where one attribute is found
> a non-zero length other attribute must be found.
>
> When I explained that I wanted to do this as a REST based service, a
> co-worker wanted to know why not a SOAP what about the WSDL? As it
> happens, in order to make a political compromise we will probably end
> up providing both Rest based and Soap Based, which the WSDL will be a
> simple one allowing xsd:any inside the message body and if anybody's
> processor can't handle that I am very very sad for them. (this is of
> course if the project gets a go-ahead, which it should, this is an
> absolutely necessary project. )
>
>
> On 10/28/05, Michael Champion <michaelc.champion@gmail.com> wrote:
> > On 10/28/05, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> > > On 10/28/05, Tech Rams <techmailing@yahoo.com> wrote:
> > > > What is in the contract that you are
> > > > not able to express in WSDL/XSD?
> > >
> > > You can't be serious, the limitations of XML Schema are so maddening
> > > and far reaching that one could fill books up just discussing the
> > > limitations.
> >
> > I'm not sure that's the question.  The one I'd like to see answered is
> > "what is in a REAL WORLD contract that you can't express in XSD, BUT
> > COULD BE EXPRESSED IN SOME OTHER DECLARATIVE SCHEMA LANGUAGE."
> >
> > Don't get me wrong ...The fact that W3C put out a schema language that
> > took the work 5 years to even begin to understand and implement
> > consistently *is* maddening.  I'm no longer convinced that it is
> > standing in the way of getting real work done, however.
> >
>




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS