[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] [Issue WSRF9] summary of alternatives
Part of this issue text states "there is no way for a client to ask what
properties are currently contained in the property document if they are not
listed in the property document schema and QueryResourceProperties is not
supported".
This suggests that the resolution of this issue should contain some
mandatory requirements on at least all WS-Resources that contain xsd:any
properties to ensure that a client can always determine which properties
are contained in a property document. That would lead either to the 1a/1b
operations needing to be mandatory or the 2a/2b resource properties needing
to be mandatory.
Since what we're trying to resolve is the structure of any dynamic parts of
the resource property document, it seems (to me) better to have a pattern
that suggests an operation on the document than to have metadata about the
document in the document. So I slightly prefer 1b with the caveats:
i) a WS-Resource with open element content in its resource property
document MUST support the message exchange of the 2 proposed new operations
ii) as suggested in the proposal for 1a/1b, we recommend use of the
optional xsi:schemaLocation attribute on each element in the response to
'GetResourcePropertyQNames'.
Regards,
Ian
Steve Graham
<sggraham@us.ibm. To: David Snelling <David.Snelling@uk.fujitsu.com>
com> cc: "WSRF" <wsrf@lists.oasis-open.org>
Subject: Re: [wsrf] [Issue WSRF9] summary of alternatives
17/06/2004 20:29
Dave:
Although I see some benefits with the approach you suggest, my concerns
still apply.
a) is hard. Even though it is algorithmic, it still requires
implementations to be able to process .xsd on the fly at runtime, too high
a bar.
b) this doesn't fit well with existing XML serialization/deserialization
engines. XML performance needs all the helpers we can give it. If we
start changing the schema dynamically, we lose the ability to pre-configure
serialization engines, and/or require a fair amount of "runtime processing"
required to get serialization engines to build new serializers. I am not
convinced this is worth it. This is starting to feel like me as
"aggressive use of XML". Been there, done that, have lowered my
"expectation" for the usefulness of most XML tooling and runtimes.
c) understand your point. But in the case where this RP doesn't appear,
what should the client do?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
David Snelling
<David.Snelling@uk.fujitsu.com> To: Steve
Graham/Raleigh/IBM@IBMUS
cc: "WSRF"
06/17/2004 05:11 AM <wsrf@lists.oasis-open.org>
Subject: Re: [wsrf]
[Issue WSRF9] summary of alternatives
Steve,
Let me push on this a bit more, as I feel the RP solution (2a) is the
most elegant.
On 16 Jun 2004, at 14:29, Steve Graham wrote:
> a) it is non trivial to take an existing schema document, find the
> xsd:any and then insert additional elements around it.
I would think it that difficult, as the RP document is mandated to have
a simple flat structure at the root element. Only xsd:any elements at
this level matter. If an xsd:any appears deeper in the tree, it's an
application problem. My naive approach would be:
if (xsd:any exists in the root element) then add new schema
definition to the root.
But I am no schema programmer.
> b) if we did an approach such as a), there is potential confusion for
> various consumers of the resource property document. Which of the now
> many "authoritative sources for the schema of that document" is in
> force
> at any one time?
> If the RP is added and then removed, there is a
> potential for significant problems when the schema a requestor has in
> hand is somehow "out of sync" with the current version reflecting the
> current set of dynamic resource properties.
> Therefore, I am being conservative here, and chose not to include this
> approach.
This is easy and covered by the RP rules. The static version in the
WSDL is always true. The definitions in the dynamic resource property
are of course subject to the fairly loose semantics on the RP document.
The fact that it may be out of sync is just a property of the fact that
it is a resource property. The service of course has exact knowledge
internally, but the RP need not be consistent with that.
Implementations could offer higher QoS on this RP along with any
others.
> c) even if we did make the behavior suggested in a) a SHOULD, it still
> leaves the requestor unclear over how to answer the question,
> especially
> when dealing with services that chose to interpret SHOULD as "OK TO
> IGNORE" (ie not implement).
I would not use any special wording here. It's just a RP with RP
semantics.
> d) the proposal was getting too big already, and I was tired of typing
> :-)
Now that I won't argue with. Thanks for putting it all together.
>
> sgg
>
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, On Demand Architecture
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
>
>
>
>
> Dave Snelling <david.snelling@uk.fujitsu.com>
>
>
> 06/16/2004 05:11 AM
> To: Steve Graham/Raleigh/IBM@IBMUS
> cc: WSRF <wsrf@lists.oasis-open.org>
> Subject: Re: [wsrf] [Issue WSRF9] summary of
> alternatives
>
>
>
>
> Steve,
>
> Let me show some ignorance. You wrote:
>
>> 2a) Use Resource Properties for Resource Property Qnames:
>
> <snip>
>
>> cons: Does not address discovery of "dynamic" resource properties
>> declaration in Question iii)
>
> Why can't we specify that any dynamic properties have their schema
> added to the wsrp:ResourcePropertyDocumentSchema on the fly? We could
> make it a SHOULD if it seems a bit demanding for some implementations.
>
>
> --
>
> Take care:
>
> Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
> Fujitsu Laboratories of Europe
> Hayes Park Central
> Hayes End Road
> Hayes, Middlesex UB4 8FE
>
> +44-208-606-4649 (Office)
> +44-208-606-4539 (Fax)
> +44-7768-807526 (Mobile)
>
>
>
> <InterScan_Disclaimer.txt>
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office)
+44-208-606-4539 (Fax)
+44-7768-807526 (Mobile)
(See attached file: InterScan_Disclaimer.txt)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]