Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: XSD restriction to a set of string values

From: "Peter Olcott" <NoSpam@---------.--->
To: NULL
Date: 12/6/2008 11:48:00 AM
"Neil Smith [MVP Digital Media]" <neil@n...> wrote in 
message news:hn2jj49nqnlq9sbm343of5l4rsc6fsmqfd@4......
> On Fri, 5 Dec 2008 08:38:22 -0800 (PST), PeteOlcott
> <PeteOlcott@g...> wrote:
>
>>On Dec 4, 7:59 am, Martin Honnen <mahotr...@yahoo.de> 
>>wrote:
>>> Peter Olcott wrote:
>>> > I need to know the syntax for restricting a type to a
>>> > specific set of string values where these string 
>>> > values are
>>> > not encoded as enumeration types.
>>>
>>> You could use a regular expression pattern e.g. this 
>>> schema
>
>>I am trying to make a SOAP interface such that the client 
>>can
>>dynamically reconfigure its graphical user interface with 
>>no
>>programming  changes and no recompile required whenever 
>>the web
>>service is updated with new capabilities. Because of this 
>>your
>>suggestion may not work. It would see that you suggestion 
>>would at
>>least require a recompile.
>>
>>What I am trying to do may not be possible with pure SOAP, 
>>and may
>>require the SOAP message to have an embedded XML payload. 
>>How would
>>this be specified in a SOAP XSD document?
>
>
> It seems clear that you asked one question, then 
> completely changed
> the parameters - it's always best to be clear about the 
> complete
> intent up front, in order not to waste peoples time 
> proposing
> solutions which don't meet your requirements.
>
> In terms of dynamically updating the XSD, I'd at least 
> consider a
> secondary validation URL which provides the modified rule 
> on the fly
>
> e.g the modified rule is dynamically generated from 
> content held in a
> DB and processed by requesting a specific but variable URL 
> on a web
> server.
>

The design criteria indicates that I need to minimize the 
number of connections, thus I am envisioning a total of two 
connections:
(1) GetInterface()
(2) GetProduct(NameValuePair List)

The way that I am envisioning this process is that the 
initial SOAP request returns the entire interface, including 
the specification of the client side graphical user 
interface. It does this in terms of a set of NameValue Pairs 
where each name is defined in terms of a type specified 
using XSD syntax. Some of these data types will be defined 
in terms of other data types to the full extent that XSD 
syntax allows.

The definition of the type of the Value associated with a 
NameValue Pair will also include information that can be 
used to dynamically create the graphical user interface on 
the client side such that the client can automatically 
reconfigure itself as new capabilities are provided by the 
web service. without any code changes or need to recompile. 
Information such as MouseOverText, 
GraphicalUserInterfaceWidgetCategory, LabelName, and 
TitleBarName will be explicitly provided.

Different forms of validation criteria need to be 
dynamically processed by the client because some aspects of 
the criteria may change from one SOAP request to the next. 
There will be at least two forms of validation:
(1) Range Checking for numeric data
(2) Checking against a list of valid strings for string 
data, this list can change from one SOAP request to the 
next.

To provide this capability I was initially envisioning that 
the interface be provided to the client as an XML payload 
within the SOAP message. Since I am new to this, I was also 
envisioning that the client might possibly have to process 
the XML and the validation manually. All of the validation 
that I have worked with in the past requires generating 
classes that are directly bound into the code, thus changing 
the criteria requires recompile.

> XSI include http://www.w3schools.com/schema/el_include.asp 
> (or in SOAP
> terms, 
> www.---.com)  is 
> one
> way I could see that working
>
> Each time the schema is loaded (assuming the parsing code 
> is set to
> not cache includes) then it should request a fresh copy of 
> the
> included schema.
>
> The included XSD schema elements need not necessarily come 
> from a
> static file source. The include should presumably specify 
> whatever
> regex is required.
>
> You could potentially also use XSL on a base schema 
> document per
> request, so it's modified on the fly that way prior to 
> validation
> being performed using the generated schema.
>
> Again you'd want to ensure the validator always requested 
> a fresh
> instance rather than caching it client side.
>
> In PHP (my favourite scripting language) I'd be making 
> SOAP calls with
> the WSDL_CACHE_NONE parameter set, to ensure a fresh copy 
> of the WSDL
> was requested for each time the SOAP object was 
> instantiated.
>
> HTH
> Cheers - Neil
> ------------------------------------------------
> Digital Media MVP : 2004-2008
> http://mvp.support.microsoft.com/mvpfaqs 




transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent