[
Lists Home |
Date Index |
Thread Index
]
I am sure this world is full of examles where XSD (and
thus WSDL) is limiting. However, the same can be said
about so many other things: XML- it is verbose and
taxing on parsing huge docs, Java - relatively slower,
and so on.
Whether or not we like it, XSD/WSDL are based on
programmatic and object-oriented data structures. If
we want to embed procedures into those data structures
(like saying I want the type to be text, but should
sent as zipped), clearly these standards are not for
it.
The co-constraints that Ian Graham mentioned, would be
the sort of enhancement we all like (though there are
ways to overcome it, like having a choice with
repeated definitions but specific variations). But the
functional constraint cannot (at least easily) be put
as part of the XSD. You cannot state in an XSD how to
derive a particular data, but only what its type and
composition can be.
But thinking a little further, I think even functional
constraints can be embedded in the XSD - for example,
you state that you expect a specific attribute to have
a specific value on the element you want to put this
constraint on. In such design, the attribute value can
be a URI that stands for the particular algorithm -
like checksum. The party creating the data then
understands that URI and accordingly generates the
data.
-rams
--- 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.
> >
>
>
-----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org
> <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at
> http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the
> subscription
> manager:
> <http://www.oasis-open.org/mlmanage/index.php>
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
|
