Re: Some requirements

Folks,

I'll try to answer these questions from the OGSI ServiceData perspective.
Steve Graham can either back me up or argue. I have tried to only state
facts, and not say anything about how I might argue the point.


On 12/6/03 8:22, "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
wrote:

> 
> All,
> 
> Few comments/questions...
>> 
>> <requirements>
>> 
>> User should be able to know what their permissions are on attributes
>> before
>> trying
>> 
> 
> Isn't permission (part of a security/policy infrastructure) orthogonal
> to specifying an interface?

For ServiceData (SD), access authorization is completely outside the OGSI
scope. Although I can see that it would be nice to know if you could access
a particular bit of SD.

> 
>> Query across attributes (in one service): what query language?

This is expected in SD, probably with Xpath/Xquery, provide queries across
all SD. According to the current spec, a service can advertise what query
processing it supports, but only "by name" access is specified.

>> Ability to know (partial?) list of attributes at design time

Yes. The service publishes a list of some of the SD elements (SDEs)
available to the client. The service may also add more SDEs dynamically.
Clearly, these would only be useful to clients that recognized the type and
understood the semantics.

>> Ability to know type of attributes ahead of time
>>
> Since attributes are going to be part of an interface, wouldn't be a
> requirement that ALL are known at design time? If attributes can be
> added/removed at runtime, the interface changes. Type-safety becomes a
> runtime issue. Personally, I like implementation-time type safety.

All declared SDEs are typed in the WSDL. Only the dynamically added ones
could show up without the client being able to know the type before hand.
 
Enforcing this on the Service Data model would be a restriction of the
current specification.


>> Input/output messages that manipulate attributes can be validated
>> against WSDL

These are defined in the GridService portType that all Grid services extend.
This has made it easy for OGSI. We were going to have a default set of
operations anyway, so there was nothing to overcome in this area. See Stece
G's slides for a summary of the operations we used.
 
>> Support for static attributes
>> 
> 
> What does static mean? Does it mean that you can specify the value of an
> attribute within the WSDL that will always be the same? If so, then
> ignore this.

OGSI SD supports the above as mutibility = 'static' SD also has the concept
of mutibility = 'constant' where the value is set once and for all at
service instantiation time.

>> Ability to restrict access on a per attribute basis.
>> 
> 
> Again, I think this is part of a security/policy infrastructure. It's
> similar to permitting/restricting access to a web service operation.

Yes. As far as OGSI is concerned, this is outside the scope of the spec. A
implementation could provide this facility, but we didn't define any
mechanism for exposing this information to the client.


>> Ability to restrict read vs. write access

This we did do: modifiable = 'true' | 'false'

>> Attributes can be inherited through WSDL 1.2 inheritance

Yes, this is true of OGSI of both declared types and values where they are
provided. 

>> Support metadata on attributes (creation date, type, description...)
>> 
> 
> Should "type" be part of the metadata or a first-class characteristic of
> the attribute?

The SD attribute/element set is (extracted from whole schema is):

<element ref="annotation" minOccurs="0"/>
<attribute name="name" type="NCName"/>
<attribute name="type" type="QName"/>
<attributeGroup ref="occurs"/>
<attribute name="nillable" type="boolean" use="optional" default="false"/>

<attribute name="mutability" default="extendable">
              <enumeration value="static"/>
              <enumeration value="constant"/>
              <enumeration value="extendable"/>
              <enumeration value="mutable"/>

<attribute name="modifiable" type="boolean" default="false"/>

<anyAttribute namespace="##other" processContents="lax"/>

<complexType name="ServiceDataValuesType">
    <sequence>
      <any namespace="##any" minOccurs="0" maxOccurs="unbounded" />
    </sequence>
</complexType>

There are also lifetime attributes associated with service data

    <attributeGroup name="LifeTimePropertiesGroup">
      <attribute ref="ogsi:goodFrom" use="optional"/>
      <attribute ref="ogsi:goodUntil" use="optional"/>
      <attribute ref="ogsi:availableUntil" use="optional"/>
    </attributeGroup>


> 
>> Allow bulk retrieval of several attributes in one operation

Yes. The find by SD names is a plural construct. Also, when an extesnion for
Xpath/Xquery is added, this would also support multiple/bulk replies.

>> 
>> Attributes can be of any schema type (simple or complex)

Yes, the type of SD is unrestricted.

>> 
>> </requirements>
>>

I hope this helps.

-- 

Take care:

    Dr. David Snelling <d.snelling@fle.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)