OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [wsia][customization] Initial ideas and outline for property meta data



Property meta data for wsia.
-----------------------------------------

1. Requirements for WSIA 1.0

i. Reading / Writing Model values
1. Initialization [1.0]
2. Incremental through interaction (transparency of property values) [1.0]
3. Termination [not 1.0]
ii. Interaction automation (Consumer initiated performInteraction) [out of band]
iii. Model augmentation (Type modification)
1. via properties [1.0]
2. defined content model for constraints [not 1.0]
3. First class support [not 1.0]
iv. Well known properties [not in protocol => not 1.0]
1. Std property names [1.5]
2. Std property types [1.5]
3. Property best practices [1.5]
v. View alteration
1. Data driven changes [1.0]
2. Consumer supplied markup [not 1.0]
vi. Producer callbacks (eg private protocol) [not 1.0 – dependent on events?]

Orthogonal requirements:
1. Reduce the possibility of run-time errors by providing property meta data
2. Support developers by providing property meta data

2. Meta data required

a. General attributes of properties as defined in its description. Independent of whether its a new language or not.

propertyName
propertyDocumentation <synopsis, description)
propertyType ( namespace:type) (Should we allow for extensibility elements here like wsdl?)
propertyScope (values: session, entity, precedence: session, entity), relationship to model? Are we ready to introduce a new concept of model?
propertyAccess (Read, Read/Write, Write, WriteOnce? MustWrite? )
propertyUsage/propertyValidity (When is it valid to manipulate the property? e.g At Initialization, after Initialization)
propertyExtensions (It should be possible to add new attributes in future)

For developer
propertyToolingHint (requirement).
propertyEditor (Seems like a nice idea to be able to specify an editing class per property type, not a requirement)

In general, its clear this specification should allow for extensibilty. Where should we allow extensibility elements, extensions, and restrictions ?
What level does cacheability apply?

b. How does the properties show up in the data objects of the operations?
i. As a property list (a list of property, value pair)?
ii. As an xforms instance?

3. Joint Interfaces
registerConsumer
performInteraction
getMarkup
setProperties
getProperties
getPropertyDescription (Can property description change during the lifetime of an entity? If it does, interaction with other calls should be specified).
cloneEntity
modifyEntity
releaseHandles - na-

4. Where it fits into the joint interfaces

performInteraction
getMarkup
setProperties
getProperties
getPropertyDescription
cloneEntity
modifyEntity

5. Interaction and sequencing
1. Properties of an entity/session can be changed in variety of ways.
2. When should the consumer ask for the markup corresponding to a propertyChange.
3. What can the consumer assume about the relative consistency between property values, it knows about and the properties at the producer.
e.g stockquote.

6. How it addresses the scenario requirements (Memory Configurator, Health Insurance, Multimedia sports portal).

Ravi Konuru
eBusiness Tools and Frameworks, IBM Research
office: 914-784-7180, tieline 8-863-7180; fax -3804



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC