Best place to use AND how to validate a Version

[Mike Logan]

I am using the "contract first" design methodology. Contract First is design
the WSDL first then design the server and client. However I must design my
XSD/XML Schema before anything.

I am developing my schema now. I have a version on my schema. However once
I start the server side code, how is the server now that the right
"complexType" is being passed?

What happens if this complexType my web service consumes needs to be
different. Should every "complexType" in my message have "schemaVersion"
element that is non-null, and check that everytime the Web Service is
generated.

OR

I also design my messages in the XML Schema. Should I check the version in
the SOAP Header?

Thanks for your input.
--
Mike Logan

[Steven Cheng[MSFT]]

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or
WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types,
we will scope them under the sample namespace(or same root namespace....)
for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine
, e.g the ASP.NET webservice handler will parse the xml content and mapping
the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
Thread-Topic: Best place to use AND how to validate a Version
thread-index: AcXaWtvmrp2mLjaLShOjAyVQmdWyMg==
X-WBNR-Posting-Host: 165.176.240.10
From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <Mi*******@community.nospam>
Subject: Best place to use AND how to validate a Version
Date: Wed, 26 Oct 2005 11:27:02 -0700
Lines: 21
Message-ID: <00**********************************@microsoft.co m>
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.public.dotnet.framework.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
microsoft.public.dotnet.framework.webservices:8365
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

I am using the "contract first" design methodology. Contract First is
design
the WSDL first then design the server and client. However I must design my
XSD/XML Schema before anything.

I am developing my schema now. I have a version on my schema. However once
I start the server side code, how is the server now that the right
"complexType" is being passed?

What happens if this complexType my web service consumes needs to be
different. Should every "complexType" in my message have "schemaVersion"
element that is non-null, and check that everytime the Web Service is
generated.

OR

I also design my messages in the XML Schema. Should I check the version in
the SOAP Header?

Thanks for your input.
--
Mike Logan

[Henrik Gøttig]

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or
WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types,
we will scope them under the sample namespace(or same root namespace....)
for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine
, e.g the ASP.NET webservice handler will parse the xml content and mapping
the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Welcome Henrick and thanks for your inputs.

I think the things you mentioned is just I've also involved in my reply.
for XML data types, they're defined by xml schema(xsd.. ). And unlike the
programming source code/ or assemblies which can have version info. The Xml
data types use namespace to identify a certain collection of data, so
namespace is a buildin feature for providing version info. In fact, we can
find many realworld example like the SOAP 1.1 and SOAP 1.2's schema

SOAP 1.1

http://schemas.xmlsoap.org/soap/envelope/
SOAP 1.2

http://www.w3.org/2001/12/soap-envelope

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
Date: Thu, 27 Oct 2005 08:03:46 +0200
From: =?ISO-8859-1?Q?Henrik_G=F8ttig?= <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Subject: Re: Best place to use AND how to validate a Version
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
In-Reply-To: <HY**************@TK2MSFTNGXA01.phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <u9**************@TK2MSFTNGP09.phx.gbl>
Newsgroups: microsoft.public.dotnet.framework.webservices
NNTP-Posting-Host: 194.239.230.244
Lines: 1
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFT NGP09.phx.gbl
microsoft.public.dotnet.framework.webservices:8371
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types, we will scope them under the sample namespace(or same root namespace....) for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine , e.g the ASP.NET webservice handler will parse the xml content and mapping the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Marvin Smit]

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or
WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types,
we will scope them under the sample namespace(or same root namespace....)
for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine
, e.g the ASP.NET webservice handler will parse the xml content and mapping
the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Henrik Gøttig]

Hi Marvin (and Steven and Mike and ???)

Thanx for joining in and it is indeed a nice topic :-)

Do you know if the question I asked about Indigo applies?
Will Indigo deal with versioning in the way, that you can several
contracts (message and datatypes) applied to the very same service?

So one could say, that this service supports version 1 and version 2 of
the contract.

I think this is one of the most under-documented "problems" of using the
web services stack. ANYONE dealing with web services in production WILL
face this issue at some point in time.
I have seen others apply "the new service approach", where a change of
contract (in an exsting message and/or datatype) results in creating a
new branch of the same service just a another endpoint.

Regards

Henrik

Marvin Smit wrote:

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.

[Steven Cheng[MSFT]]

Hi Marvin,

Thanks for your good inputs.
I agree with the things you mentioned. Also as for the below:

===========
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)
============

Yes, .NET type(with xml serliazation attribute) can not 100% express what
XSD can do. However, we can accomplish some of those rules in XSD through
programming language's code logic. e.g. the
'maxInclusive', maxLength, etc)

can be done through code validtion in the property's get/set accessor....
and that's also why we use .NET type mapping.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)



--------------------
From: Marvin Smit <ma*********@gmail.com>
Newsgroups: microsoft.public.dotnet.framework.webservices
Subject: Re: Best place to use AND how to validate a Version
Date: Thu, 27 Oct 2005 10:06:00 +0200
Message-ID: <54********************************@4ax.com>
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
X-Newsreader: Forte Free Agent 3.0/32.763
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: ab***@chello.nl
Organization: chello.nl
Lines: 102
NNTP-Posting-Host: 62.194.138.116 (62.194.138.116)
NNTP-Posting-Date: Thu, 27 Oct 2005 10:03:21 +0200
X-Trace: d55ff436089c99b672fd116176
Path:
TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfee d00.sul.t-online.de!newsfe
ed01.sul.t-online.de!t-online.de!newsfeed01.chello.at!amsnews01.chello.co m!a
msnews14.chello.com!news.chello.nl.POSTED!not-for-mail
microsoft.public.dotnet.framework.webservices:8377
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types, we will scope them under the sample namespace(or same root namespace....) for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine , e.g the ASP.NET webservice handler will parse the xml content and mapping the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Mike Logan]

Just a followup:

I like the idea of using versions in the namespace. However, Steven, in
your example, the datatypes schema was seperate from the message schema. If
you are on say:

"http://mywebservice/datatypes/2005/10/27", and
"http://mywebservice/contract/2005/10/27"

then change to

"http://mywebservice/datatypes/2005/12/5". If this happens I should also
have to change my contract/message schema, correct?

Is there a place that documents "Best Practices" for this? I was initially
defining datatypes and messages in the same schema. I would assume that is
alright for a small system?

Thanks for the help.
--
Mike Logan
"Marvin Smit" wrote:

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or
WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types,
we will scope them under the sample namespace(or same root namespace....)
for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine
, e.g the ASP.NET webservice handler will parse the xml content and mapping
the xml data to types through namespace. So when you need to define new
version of the datatypes, you can just define a new schema or other xml
data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hi Mike,

Of course, we can defining datatypes and messages in the same schema.
Actually there is no definite rules on this. If you need to adopt some best
practice, you may try searching some existing webservice contracts/types
schema on the net and get some ideas from them.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
Thread-Topic: Best place to use AND how to validate a Version
thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg==
X-WBNR-Posting-Host: 165.176.240.10
From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <Mi*******@community.nospam>
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
<54********************************@4ax.com>
Subject: Re: Best place to use AND how to validate a Version
Date: Thu, 27 Oct 2005 03:52:04 -0700
Lines: 128
Message-ID: <BD**********************************@microsoft.co m>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
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.public.dotnet.framework.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.webservices:8381
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Just a followup:

I like the idea of using versions in the namespace. However, Steven, in
your example, the datatypes schema was seperate from the message schema.
If
you are on say:

"http://mywebservice/datatypes/2005/10/27", and
"http://mywebservice/contract/2005/10/27"

then change to

"http://mywebservice/datatypes/2005/12/5". If this happens I should also
have to change my contract/message schema, correct?

Is there a place that documents "Best Practices" for this? I was initially
defining datatypes and messages in the same schema. I would assume that is
alright for a small system?

Thanks for the help.
--
Mike Logan
"Marvin Smit" wrote:

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types, we will scope them under the sample namespace(or same root namespace....) for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine , e.g the ASP.NET webservice handler will parse the xml content and mapping the xml data to types through namespace. So when you need to define new version of the datatypes, you can just define a new schema or other xml data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hi Mike,

Any further questions on this issue? If there're anything else we can help,
pleas feel free to post here.
Thanks ,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
X-Tomcat-ID: 38917779
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
<54********************************@4ax.com>
<BD**********************************@microsoft.co m>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_0001_4E822A8D"
Content-Transfer-Encoding: 7bit
From: st*****@online.microsoft.com (Steven Cheng[MSFT])
Organization: Microsoft
Date: Fri, 28 Oct 2005 02:15:50 GMT
Subject: Re: Best place to use AND how to validate a Version
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices
Message-ID: <z5**************@TK2MSFTNGXA01.phx.gbl>
Newsgroups: microsoft.public.dotnet.framework.webservices
Lines: 325
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.webservices:8396
NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182

Hi Mike,

Of course, we can defining datatypes and messages in the same schema.
Actually there is no definite rules on this. If you need to adopt some best
practice, you may try searching some existing webservice contracts/types
schema on the net and get some ideas from them.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
Thread-Topic: Best place to use AND how to validate a Version
thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg==
X-WBNR-Posting-Host: 165.176.240.10
From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <Mi*******@community.nospam>
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
<54********************************@4ax.com>
Subject: Re: Best place to use AND how to validate a Version
Date: Thu, 27 Oct 2005 03:52:04 -0700
Lines: 128
Message-ID: <BD**********************************@microsoft.co m>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
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.public.dotnet.framework.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.webservices:8381
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Just a followup:

I like the idea of using versions in the namespace. However, Steven, in
your example, the datatypes schema was seperate from the message schema.
If
you are on say:

"http://mywebservice/datatypes/2005/10/27", and
"http://mywebservice/contract/2005/10/27"

then change to

"http://mywebservice/datatypes/2005/12/5". If this happens I should also
have to change my contract/message schema, correct?

Is there a place that documents "Best Practices" for this? I was initially
defining datatypes and messages in the same schema. I would assume that is
alright for a small system?

Thanks for the help.
--
Mike Logan
"Marvin Smit" wrote:

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:

Hi Mike,

For the Xml Types we defined in Xml schemas for webservice's data type or WSDL's message element type, they're all identified and scoped by xml
namespace. So generally, for the xml data types and message element types, we will scope them under the sample namespace(or same root namespace....) for example:

we can define the root namespace of our webservice as:

http://myservice/

and the xml schema can use a sub namespace like:

http://myservice/datatypes

wsdl message types can use

http://myservice/contract

as namespace. There is no version info for xml types, just use XML
namespace to identify their scope. Also, at runtime, the webservice engine , e.g the ASP.NET webservice handler will parse the xml content and mapping the xml data to types through namespace. So when you need to define new version of the datatypes, you can just define a new schema or other xml data with new namespace....

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Aditya]

A major issue I've been facing - It is often written that in document
literal style - one has a lot of flexibility and one can do two things
specifically -

1. Validate the SOAP body against a schema
2. Use an XSLT stylesheet to modify the SOAP body.

It seems from a previous post - schema validation is not automatically
done. How does one do it?

At what point can the stylesheet be applied - since the XML gets
converted to objects before I can do anything with it..

Thanks!

Steven Cheng[MSFT] wrote:

Hi Mike,

Any further questions on this issue? If there're anything else we can help,
pleas feel free to post here.
Thanks ,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
X-Tomcat-ID: 38917779
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
<54********************************@4ax.com>
<BD**********************************@microsoft.co m>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_0001_4E822A8D"
Content-Transfer-Encoding: 7bit
From: st*****@online.microsoft.com (Steven Cheng[MSFT])
Organization: Microsoft
Date: Fri, 28 Oct 2005 02:15:50 GMT
Subject: Re: Best place to use AND how to validate a Version
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices
Message-ID: <z5**************@TK2MSFTNGXA01.phx.gbl>
Newsgroups: microsoft.public.dotnet.framework.webservices
Lines: 325
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.webservices:8396
NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182

Hi Mike,

Of course, we can defining datatypes and messages in the same schema.
Actually there is no definite rules on this. If you need to adopt some best
practice, you may try searching some existing webservice contracts/types
schema on the net and get some ideas from them.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

--------------------
Thread-Topic: Best place to use AND how to validate a Version
thread-index: AcXa5HfN7e4LdWiCSDyZuPNob21Ngg==
X-WBNR-Posting-Host: 165.176.240.10
From: "=?Utf-8?B?TWlrZSBMb2dhbg==?=" <Mi*******@community.nospam>
References: <00**********************************@microsoft.co m>
<HY**************@TK2MSFTNGXA01.phx.gbl>
<u9**************@TK2MSFTNGP09.phx.gbl>
<54********************************@4ax.com>
Subject: Re: Best place to use AND how to validate a Version
Date: Thu, 27 Oct 2005 03:52:04 -0700
Lines: 128
Message-ID: <BD**********************************@microsoft.co m>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
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.public.dotnet.framework.webservices
NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.webservices:8381
X-Tomcat-NG: microsoft.public.dotnet.framework.webservices

Just a followup:

I like the idea of using versions in the namespace. However, Steven, in
your example, the datatypes schema was seperate from the message schema.
If
you are on say:

"http://mywebservice/datatypes/2005/10/27", and
"http://mywebservice/contract/2005/10/27"

then change to

"http://mywebservice/datatypes/2005/12/5". If this happens I should also
have to change my contract/message schema, correct?

Is there a place that documents "Best Practices" for this? I was initially
defining datatypes and messages in the same schema. I would assume that is
alright for a small system?

Thanks for the help.
--
Mike Logan
"Marvin Smit" wrote:

Hi Guys,

This is such a nice topic i couldn't resist putting my 2ct. in ;-)

The versioning scheme suggested by Henrik is a very common one. You
essentially have the following options;

- Modify your namespace-uri for different versions (*the example
below)
This is a very strict way of versioning. The problem is that for each
new version your clients will have to "update reference & recompile".

- include version attribute in your schema
This is how it was intended, but i no of NONE XML-XSD parser that will
actually read/use the version attribute and be able to have multiple
versions of the same schema.

Please be aware that when you are developing a WebService with .Net
(same goes for Axis AFAIK) that;

- XSD Validation on the incomming message is NOT THERE by default.
- The deserialization happens with "Defaults" (i.e. an element that is
not found will be filled with ; 0 for numbers, "" for strings, etc)
- The .Net types representing the XSD complextypes are not 100% XSD
equivilant. (You loose the facets in the .Net type, like
'maxInclusive', maxLength, etc)

Hope this helps,

Marvin Smit.
On Thu, 27 Oct 2005 08:03:46 +0200, Henrik Gøttig <[e-mail]>
wrote:

Hi Steven and Mike

Sorry for inteferring your thread but..

I don't know if it is considered "bad practice", but one could also
embed versioninfo in the XML namespace as:

http://myservice/datatypes/customer/10
for version 1.0 of the customer datatype

and http://myservice/datatypes/customer/11
for the version 1.1 of the customer datatype

Similar approach could be taken with the contracts.

Anyway. Are there any drawbacks with this approach?
One thing maybe.. A 1.0 client proxy will no be able to "talk" to a 1.1
Webservice, will it?

Isn't it right that Indigo deal with this, as there can be many
"contracts" assigned to a single service?

Looking forward to hear your insights.

Regards

Henrik

Steven Cheng[MSFT] wrote:
> Hi Mike,
>
> For the Xml Types we defined in Xml schemas for webservice's data type or> WSDL's message element type, they're all identified and scoped by xml
> namespace. So generally, for the xml data types and message element types,> we will scope them under the sample namespace(or same root namespace....)> for example:
>
> we can define the root namespace of our webservice as:
>
> http://myservice/
>
> and the xml schema can use a sub namespace like:
>
> http://myservice/datatypes
>
> wsdl message types can use
>
> http://myservice/contract
>
> as namespace. There is no version info for xml types, just use XML
> namespace to identify their scope. Also, at runtime, the webservice engine> , e.g the ASP.NET webservice handler will parse the xml content and mapping> the xml data to types through namespace. So when you need to define new> version of the datatypes, you can just define a new schema or other xml> data with new namespace....
>
> Thanks,
>
> Steven Cheng
> Microsoft Online Support
>
> Get Secure! www.microsoft.com/security
> (This posting is provided "AS IS", with no warranties, and confers no
> rights.)
>
>
>