[
Lists Home |
Date Index |
Thread Index
]
-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@comcast.net]
Sent: Tuesday, June 11, 2002 2:47 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] W3C Schema: Resistance is Futile, says Don Box
[bryan]
> Finally the fact that .Net users use it all the time; does this apply
to
> Schemas that they generate for instance documents - forgive me here I
> seem to remember seeing a schema generator for VS.Net sometime, as I
> just use the Framework I'm unfamiliar with the functionalities of
VS.Net
> - does it apply to Schemas that others have written, or does it apply
to
> Schemas that they themselves author? I submit that if it applies to
the
> second then the "accounting" for development time could be screwed up
> without accurate measurement of time taken to write the schema, which
I
> bet could have been more quickly written in another language.
[Thomas]
>Here's how it works in .NET, including .NET Studio. The xml schema is
>basically invisible to the programmer. Say you want to provide a "Web
>Service". You start a new Web Services form in .NET Studio and define
the
>classes that will respond the the service requests. Being .Net, you
can >use C++, C#, VB, ... When you compile everything, .NET creates a
WSDL >service description, which includes an xml schema that describes
the data >types for the input and output. This happens behind the
scenes; the user >does not write the schema nor select the translation
to xsd data types.
>To access to service, you create, in .NET Studio, a form which is more
or
>less a web page with Microsoft extensions for server-side processing
(which
>are added by the .NET machinery, not by the programmer). You tell it
to >use
>your web service. When you compile, behind the scenes .NET refers to
the
>wsdl file, reads the embedded schema in that file, and creates
>corresponding classes to turn a request instance into parameters of the
>corresponding data types and pass them to the code that does the
service. >IIRC, it also generates code that checks the received
parameters to see >that they are the right type.
>You can also start with a wsdl file that you create outside of .NET.
That
>sometimes does not work - for example, if you use a urn: scheme instead
of
>an http: scheme for the target namespace, it gets rejected by the
machinery
>(I can't imagine why), but I think that normally it does work.
>So you can see that .NET provides roundtripping translation of normal
>programming data types, and uses schemas, while the user does not see
or
>touch schemas, wsdl, or even xml.
I wasn't thinking so much about using Web Services, Which might have
been the idea behind the original thread, if so I apologize. What I was
particularly referring to was applications in which the schema is not
basically invisible to the programmer, thus the reference to
System.Xml.XmlConvert. However I think the rest of the comments I made
apply just as well to cases in which the Schema is invisible(I've always
hated the idea of things being invisible to me, I suppose this is why
I've avoided the Visual Studio.Net release, I don't want to go back to
interfaces being hidden by my IDE).
Since I have kept away from Web Services inside of .Net I'm unfamiliar
with how it handles WSDL, however doesn't the generation of an embedded
schema inside the Wsdl seem somewhat wasteful?
I'm wary of Microsoft's WSDL generation, Schemas, and different SOAP
API's due to some bad experiences I had working with the high-level API
and then finding that without some fiddling SOAP messages expected to
work with the high-level would not interact correctly with the
low-level. Unfortunately cannot remember what the problem was any
longer, but all of the various bugs encountered did help me to win a
philosophical battle with my co-workers about how SOAP should be
implemented, with us finally going the PocketSOAP, XmlHttp way. I say
this cause the remark about WSDL's created outside .NET not working
sometimes reminded me of it.
|
