RE: [wsrp][wsia] Re: Proposal for simple properties mechanism bas edon XForms

[Gil Tayar <Gil.Tayar@webcollage.com>]

Tim,

Yup. Same thing. The differences are minor (except for the fact that you did
not ignore the "scope" issue).

To your questions on the differences:
1-2. On the question of placeholders/defaults. I tried to be true to the
XForms "philosophy" where an instance is always there, and where "bind" is
optional. But, yes, yours is simpler. I prefer simpler.

3. In your proposal, contrary to what you said at the beginning of the
document ("Note that both "flat" and "hierarchical" models are possible"),
you support only a flat model. This is because "getProperties" receives a
property name list, and thus supports only the flat model. This is my
"simple" model. I actually prefer this model, and do not want to make it
more general than this (look at BPEL4WS, which also perceives properties as
name value pairs). I prefer simpler, and thus prefer your approach.

4. In your document you did not discuss any other bind attributes except
"type". What I tried to do was create a simple model first - let's give the
implementors of v1.0 of WSRP/WSIA a simple time by not forcing them to
understand/use all bind attributes. I stick with this - v1.0 should not be a
be all/end all specification. It should be as minimal as possible. Any added
attribute will incur its discussions. One cannot say "support XForms 1.0
bind attributes" in the spec and leave it at that. There are _always_
implications to these type of things, which I prefer to attack only after
some field experience in WSRP/WSIA has been collected. As I said - I prefer
simpler, and thus prefer my approach.

Some Questions regarding scope:

1. Can I indicate in the "getProperty" to what scope the property I want to
query the value belongs to? (e.g. get me the value of "X" from scope
session) It seems like it can't. Does this mean that both scopes occupy the
same namespace? (i.e. I can't have two properties with the same name, but in
different scopes) If so, maybe the "scope" is not an attribute of the
_model_, but actually of the _bind_. This will state the above namespace
rule more clearly.

2. Can I have an entity scope property that can also be modified at
session-scope? For example, the entity property is "GreetingText", with a
default value of "Hello, y'all", but I can change it per session to "Hello,
%username%".

Gil

-----Original Message-----
From: Timothy N. Jones [mailto:tim@crossweave.com]
Sent: Tue, August 27, 2002 00:35
To: Gil Tayar
Cc: wsrp@lists.oasis-open.org; wsia@lists.oasis-open.org
Subject: [wsrp][wsia] Re: Proposal for simple properties mechanism based
on XForms


Gil,

Thanks for giving this some thought and developing a proposal.  In last
week's 
WSIA customization call we also discussed this problem, and after iterating 
over a few alternatives, converged to essentially the same solution as you 
(which gives me additional confidence).  I took an action item to write up
and 
publish our proposal, but other tasks in the office kept me too busy and you

beat me to it.  

Nonetheless, attached is the solution the customization group has been 
discussing, framed as a substitute for the existing property chapter in the 
joint spec (0.4).  I think it is very similar to your idea, with a couple 
of minor differences:

- we did not include the notion of default type bindings.  
- you suggest that getPropertyDescription() should return empty placeholders

for instance data (i.e., the instance subtree without the leaves).  In our 
proposal, all properties must be explicitly bound, and thus given the set of

bindings with their XPath references it is possible to automatically
construct 
the property tree.  For example, given:
 <model>
  <bind ref="foo" .../>
  <bind ref="bar" .../>
 <model>
The corresponding
 <instance>
  <foo/>
  <bar/>
 </instance>
structure is implied.

I would like to better understand the motivation for your simplicity 
constraints and their relation to the extension items you listed -- are
there 
to be three classes of property models?

I have concerns about leaving adherance to the other <bind> attributes to 
extensions.  For example, I question whether it is reasonable to specify
that
even a simple Consumer may just ignore a "readonly" constraint placed on a 
property by a Producer.

Are extensions 3 and 4 different from 1 and 2?

Regards,
Tim