W3C home > Mailing lists > Public > public-ws-desc-state@w3.org > July 2003

RE: c) mapping to requirements

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Sun, 20 Jul 2003 23:16:58 +0100
Message-ID: <BC28A9E979C56C44BCBC2DED313A447001EC322D@bond.ncl.ac.uk>
To: <public-ws-desc-state@w3.org>


> 1) User should be able to know what their permissions are on
> before trying
> - it seems that none of the approaches in [2] make achieving this
> requirement easier or harder. It seems that the key to meeting this is
> providing an extensibility element that allows other groups to define
> elements (from some security namespace) to decorate the attributes.
> it would be more difficult with an approach such as c) from [2] to
> this.
> - furthermore, the access control can still be broadly applied at the
> get()
> and set() methods.

I believe that this is orthogonal to the definition of an attribute.
Other specifications should address this (like WS-Policy for example).

> 2) Query across attributes (in one service): what query language?
> - this cannot be achieved by any proposal but d) from [2].
> 3) Ability to know (partial?) list of attributes at design time
> - it seems that all the proposals, even the dread c) from [2] can meet
> this. Although c) from [2] requires additional processing (to do the
> pattern match detect across all getXXX and setXXX patterns in all
> interfaces, this is not as straight forward as having the meta data
> modelled in XML and immediately processable from WSDL tooling.
> 4) Ability to know type of attributes ahead of time
> - Again, this seems supported from all of the proposals. Again, the
> c) from [2] supports this but requires more effort for tooling etc.

I don't see 3 and 4 as very useful although I agree that they can be
supported. Even today one can imagine a service changing the set of
available operations at runtime. Whether this is going to be used by the
community is a different manner.

> 5) Input/output messages that manipulate attributes can be validated
> against WSDL
> - This is subject to interpretation.  Proposals related to d) from [2]
> make
> it easy.  Proposals a) or b) from [2] cannot be validated directly,
> the operations corresponding to attribute get/set are not explicitly
> modelled.  However a case can be made that all the information is
> available
> in the attribute element(s) within the wsdl interface(s) to
> the
> implicit get/set operations and thereby validate them.
> Proposals b) and d) from [2] are cannot be completed validated in all
> cases
> because they do not support strong typing. But recall: strong typing
> for
> the weak minded :-).

My proposal to model attributes as messages would solve this in the same
way it's done for WSDL operations.

Unlike Graham, I suggest that weak typing is for those who don't know
how to design interfaces ;-) Weak typing cause interoperability
nightmares, especially in the world of Web Services.

> 6) Support for static attributes
> - This seems to be supported by all proposals except c) from [2].
> Proposal
> d) from [2] addresses this well. Additional metadata (using open
> would be a required extension that we would need to add to proposal a)
> b) to support this requirement.

I would like to see an example of static attributes. I am not convinced
that are either needed or the information that they are supposed to
convey cannot be captured by wsdl:feature and wsdl:property.

> 7) Ability to restrict access on a per attribute basis.
> - This seems to be doable by all proposals. However, it is not clear
> this point that security meta-data and behaviour would be something we
> model explicitly in the WSDL extension, or leave to be satisfied other
> working groups/task forces.

Why is this different from 1?

> 8) Ability to restrict read vs. write access
> - This seems to be satisfied by all proposals in [2].
> 9) Attributes can be inherited through WSDL 1.2 inheritance
> - All proposals address this, proposal c) from [2] as usual seems to
> this a little harder to pull off.
> 10) Support metadata on attributes (creation date, type,
> - Proposal c) from [2] is the only proposal that does not address

Are you suggesting that attributes like "creation date" should be
modelled in WSDL or that extensibility mechanisms would be used?

> 11) Allow bulk retrieval of several attributes in one operation
> - Only proposal d) from [2] would support this.
> 12) Attributes can be of any schema type (simple or complex)
> - All proposals from [2] support this.


Received on Sunday, 20 July 2003 18:17:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:55 UTC