[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][wsia] Re: Proposal for simple properties mechanism bas edon XForms
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC