Webmethod Accepting XmlDocument as argument, with WSDL reflecting

[MattBell]

I've tried to search for an answer to this without much success, and I think
it's probably a common thing to do:
I have a web service I want to accept an XmlDocument as an argument which
conforms to a specific XSD that is defined. Right now when I declare
XmlDocument as my argument, it puts the old xml:any type in. How do I change
that to reflect the XSD that I'm looking for?

Thanks for any Help!

[Dan Rogers]

Hi Matt,

There is no way to infer a specific document type when the input type is
XmlNode, XmlElement, etc. The reason is that these are the XML equivalent
of a generic object class. This is why in the WSDL you see that the
service is saying that it is capable of processing any type at all, which
is a very tall order indeed.

In order to get the WSDL to reflect the type you wish to support, you need
to use a type for inputs/return that is much more strongly typed. In your
case, you have a specific type in mind, so what you need to do is create a
.NET equivalent class that when serialized creates/consumes XML that
adheres to the rules you have defined in an XML schema.

In cases where you are starting from schema, you can use tools like XSD.exe
or XsdObjectGen (or some other similar tools) to create .NET classes that
mirror your schema intent. A caveat is that not everything that is
describable in XML schema is mappable to object based type systems, but if
you are careful to choose only the subset of base types that appear in XSD,
CLR and Java when you define your schema, you'll be well on your way using
one of these tools.

Once you create the assembly/classes that represent the schema defined
structures, you then use these via assembly reference or via direct
inclusion into your web service project (e.g. add reference, or add
source). Then you simply change your method signatures to use the strongly
typed classes instead of XML.

At runtime, this means your methods can be called as if they were being
passed the objects that you generated. This saves you a world of
programming headaches, since you don't have to interweve Xpath/XQuery code
into your business logic.

I hope this helps

Dan Rogers
Microsoft Corporation
--------------------
Thread-Topic: Webmethod Accepting XmlDocument as argument, with WSDL
reflecting
thread-index: AcTZgM1GODL9hAW EQOu/8CjabQLoOA==
X-WBNR-Posting-Host: 68.157.154.79
From: "=?Utf-8?B?TWF0dEJlbGw =?=" <Ma******@discu ssions.microsof t.com>
Subject: Webmethod Accepting XmlDocument as argument, with WSDL reflecting
Date: Fri, 3 Dec 2004 13:41:09 -0800
Lines: 8
Message-ID: <05************ *************** *******@microso ft.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Newsgroups: microsoft.publi c.dotnet.framew ork.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.p hx.gbl 10.40.1.29
Path: cpmsftngxa10.ph x.gbl!TK2MSFTNG XA01.phx.gbl!TK 2MSFTNGXA03.phx .gbl
Xref: cpmsftngxa10.ph x.gbl
microsoft.publi c.dotnet.framew ork.webservices :7819
X-Tomcat-NG: microsoft.publi c.dotnet.framew ork.webservices

I've tried to search for an answer to this without much success, and I
think
it's probably a common thing to do:
I have a web service I want to accept an XmlDocument as an argument which
conforms to a specific XSD that is defined. Right now when I declare
XmlDocument as my argument, it puts the old xml:any type in. How do I
change
that to reflect the XSD that I'm looking for?

Thanks for any Help!

[Drew Marsh]

Dan Rogers wrote:

There is no way to infer a specific document type when the input type
is XmlNode, XmlElement, etc. The reason is that these are the XML
equivalent of a generic object class. This is why in the WSDL you see
that the service is saying that it is capable of processing any type
at all, which is a very tall order indeed.

In order to get the WSDL to reflect the type you wish to support, you
need to use a type for inputs/return that is much more strongly typed.
In your case, you have a specific type in mind, so what you need to do
is create a .NET equivalent class that when serialized
creates/consumes XML that adheres to the rules you have defined in an
XML schema.

... or write the WSDL by hand and continue on the path of pure XML. ;)

Remember, there's nothing that says your web service needs to actually generate
the WSDL. You can put your static WSDL file right up on the web server with
the ASMX and tell people to hit that URL instead of Foo.asmx?wsdl. It all
depends on how much time you want to spend getting your .NET model inline
with your XSD model or vice/versa. If the models are simple it's usually
not as big of an issue.

HTH,
Dre

[Dan Rogers]

I agree here completely. If the messages are really simple, it's six of
one or half dozen of the other. When the messages start to get complex
(think purchase order, employee data, etc), then I think it tilts to the
code-generation from schema side.

The hardest thing to do with raw XML, from my experience, is to create and
output XML that is schema compliant. This is why I recommend even for
simple structures to start with the schema, generate .NET classes, and use
those.

If you choose to post a static WSDL or use a generated one, this is
orthagonal, as long as what you post as a description corresponds with what
your service consumes and emits.

Dan
--------------------
Message-ID: <96************ *********@msnew s.microsoft.com >
From: Drew Marsh <dr****@hotmail .no.spamming.co m>
Subject: RE: Webmethod Accepting XmlDocument as argument, with WSDL
reflecting
References: <tC************ **@cpmsftngxa10 .phx.gbl>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 381.17
Newsgroups: microsoft.publi c.dotnet.framew ork.webservices
Date: Fri, 03 Dec 2004 15:37:07 -0800
NNTP-Posting-Host: 65.223.252.240
Lines: 1
Path:
cpmsftngxa10.ph x.gbl!TK2MSFTNG XA03.phx.gbl!TK 2MSFTNGP08.phx. gbl!TK2MSFTNGP1 4
.phx.gbl
Xref: cpmsftngxa10.ph x.gbl
microsoft.publi c.dotnet.framew ork.webservices :7838
X-Tomcat-NG: microsoft.publi c.dotnet.framew ork.webservices

Dan Rogers wrote:

There is no way to infer a specific document type when the input type
is XmlNode, XmlElement, etc. The reason is that these are the XML
equivalent of a generic object class. This is why in the WSDL you see
that the service is saying that it is capable of processing any type
at all, which is a very tall order indeed.

In order to get the WSDL to reflect the type you wish to support, you
need to use a type for inputs/return that is much more strongly typed.
In your case, you have a specific type in mind, so what you need to do
is create a .NET equivalent class that when serialized
creates/consumes XML that adheres to the rules you have defined in an
XML schema.

.. or write the WSDL by hand and continue on the path of pure XML. ;)

Remember, there's nothing that says your web service needs to actually
generate
the WSDL. You can put your static WSDL file right up on the web server with
the ASMX and tell people to hit that URL instead of Foo.asmx?wsdl. It all
depends on how much time you want to spend getting your .NET model inline
with your XSD model or vice/versa. If the models are simple it's usually
not as big of an issue.

HTH,
Drew

[MattBell]

Just wanted to say thanks a whole bunch for these answers, they work like a
charm. My infopath form now automatically knows what columns I'm looking for
and will be returning!

"Dan Rogers" wrote:

I agree here completely. If the messages are really simple, it's six of
one or half dozen of the other. When the messages start to get complex
(think purchase order, employee data, etc), then I think it tilts to the
code-generation from schema side.

The hardest thing to do with raw XML, from my experience, is to create and
output XML that is schema compliant. This is why I recommend even for
simple structures to start with the schema, generate .NET classes, and use
those.

If you choose to post a static WSDL or use a generated one, this is
orthagonal, as long as what you post as a description corresponds with what
your service consumes and emits.

Dan
--------------------
Message-ID: <96************ *********@msnew s.microsoft.com >
From: Drew Marsh <dr****@hotmail .no.spamming.co m>
Subject: RE: Webmethod Accepting XmlDocument as argument, with WSDL
reflecting
References: <tC************ **@cpmsftngxa10 .phx.gbl>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
X-Newsreader: JetBrains Omea Reader 381.17
Newsgroups: microsoft.publi c.dotnet.framew ork.webservices
Date: Fri, 03 Dec 2004 15:37:07 -0800
NNTP-Posting-Host: 65.223.252.240
Lines: 1
Path:
cpmsftngxa10.ph x.gbl!TK2MSFTNG XA03.phx.gbl!TK 2MSFTNGP08.phx. gbl!TK2MSFTNGP1 4
.phx.gbl
Xref: cpmsftngxa10.ph x.gbl
microsoft.publi c.dotnet.framew ork.webservices :7838
X-Tomcat-NG: microsoft.publi c.dotnet.framew ork.webservices

Dan Rogers wrote:

There is no way to infer a specific document type when the input type
is XmlNode, XmlElement, etc. The reason is that these are the XML
equivalent of a generic object class. This is why in the WSDL you see
that the service is saying that it is capable of processing any type
at all, which is a very tall order indeed.

In order to get the WSDL to reflect the type you wish to support, you
need to use a type for inputs/return that is much more strongly typed.
In your case, you have a specific type in mind, so what you need to do
is create a .NET equivalent class that when serialized
creates/consumes XML that adheres to the rules you have defined in an
XML schema.

.. or write the WSDL by hand and continue on the path of pure XML. ;)

Remember, there's nothing that says your web service needs to actually
generate
the WSDL. You can put your static WSDL file right up on the web server with
the ASMX and tell people to hit that URL instead of Foo.asmx?wsdl. It all
depends on how much time you want to spend getting your .NET model inline
with your XSD model or vice/versa. If the models are simple it's usually
not as big of an issue.

HTH,
Drew