Re: [wsrf] [Issue WSRF9] summary of alternatives

[Steve Graham <sggraham@us.ibm.com>]

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> 06/17/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 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)


This e-mail has been scanned by Trend InterScan Software.

This e-mail (and its attachment(s) if any) is intended for the named 
addressee(s) only. It may
contain information which is privileged and confidential within the 
meaning of the applicable law.
Unauthorised use, copying or disclosure is strictly prohibited and may 
be unlawful.

If you are not the intended recipient please delete this email and 
contact the sender via email return.

Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility 
for changes made to this email after
it was sent. The views expressed in this email may not necessarily be 
the views held by FLE.

Unless expressly stated otherwise, this email does not form part of a 
legally binding contract
or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).