[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsrf] Issue 10: Concrete proposals for Metadata (Action Item)
Metadata AI for WSRF. Will be discussed on the next WSRF telecon.
Tom
----- Forwarded by Tom Maguire/Hawthorne/IBM on 09/21/2004 04:20 AM -----
Tom
Maguire/Hawthorne
/IBM@IBMUS To
wsrf@lists.oasis-open.org
09/17/2004 03:46 cc
PM
Subject
[wsrf] Issue 10: Concrete proposals
for Metadata (Action Item)
There are several ways for WSRF to capture metadata associated with a
particular portType.
Add metadata to portType in annotations
Use the xs:documentation element to annotate components in WSDL1.1 and xsd
with additional metadata.
<element name="pt1ResourceProperties">
<complexType>
<sequence>
<element ref="type1" minOccurs="0" maxOccurs="1">
<documentation>
<wsrf:propertyMetadata
mutability="mutable"
modifiability="read-only" />
</documentation>
</element>
<element ref="type2" minOccurs="0" maxOccurs="1">
<documentation>
<wsrf:propertyMetadata
mutability="mutable"
modifiability="read-write" />
</documentation>
</element>
</sequence>
</complexType>
</element>
<element name="type1" type="xs:string"/>
<element name="type2" type="xs:string"/>
<portType name="pt1" wsrp:ResourceProperties="pt1ResourceProperties">
<operation name="GetResourceProperty">
<documentation>
<wsrf:operationMetadata
idempotent="true" />
</documentation>
<input name="GetResourcePropertyRequest"
message="wsrp:GetResourcePropertyRequest" />
<output name="GetResourcePropertyResponse"
message="wsrp:GetResourcePropertyResponse" />
<fault name="ResourceUnknownFault"
message="wsrp:ResourceUnknownFault" />
<fault name="InvalidResourcePropertyQNameFault"
message="wsrp:InvalidResourcePropertyQNameFault" />
</operation>
</portType>
Pros:
Uses established extensibility mechanism
Cons:
Mixed content of xs:documentation pretty ugly
Metadata is spread all over the place
Does not allow implementation specific extension of metadata;
metadata is only expressible at the type level
Confuses roles of authorship; the person with the knowledge of the
metadata might not have write access to xsd or wsdl
Substantial change to existing specifications; granularity of
expression forces lots of wsdl and xsd changes
No ability to have metadata on XML Schema attributes
Not sure how to add metadata for components that are not reflected in
WSDL or xsd (notifications, relationships, others?)
Add metadata to portType through attachments (ala policy attachments)
Use open attribute capabilities to attach metadata to components in WSDL1.1
and xsd.
<xs:schema>
<xs:attribute name="metadataURIs" type="list of xs:anyURI"/>
</xs:schema>
<element name="pt1ResourceProperties">
<complexType>
<sequence>
<element ref="type1" minOccurs="0" maxOccurs="1"
wsrf:metadataURIs="http://example.com/metadata#MUTABLE
"http://example.com/metadata#READ-ONLY"; />
<element ref="type2" minOccurs="0" maxOccurs="1"
wsrf:metadataURIs="http://example.com/metadata#MUTABLE
"http://example.com/metadata#READ-WRITE"; />
</sequence>
</complexType>
</element>
<element name="type1" type="xs:string"/>
<element name="type2" type="xs:string"/>
<portType name="pt1" wsrp:ResourceProperties="pt1ResourceProperties">
<operation name="GetResourceProperty"
wsrf:metadataURIs="http://example.com/metadata#IDEMPOTENT"; />
<input name="GetResourcePropertyRequest"
message="wsrp:GetResourcePropertyRequest" />
<output name="GetResourcePropertyResponse"
message="wsrp:GetResourcePropertyResponse" />
<fault name="ResourceUnknownFault"
message="wsrp:ResourceUnknownFault" />
<fault name="InvalidResourcePropertyQNameFault"
message="wsrp:InvalidResourcePropertyQNameFault" />
</operation>
</portType>
Pros:
Mechanism that is proposed for WS-Policy
Metadata in a separate document
Cons:
URI dereferencing is not clear
Confuses roles of authorship (less then documentation approach)
Metadata attachments are spread all over the place (potentially
metadata is spread all over the place as well)
Does not allow implementation specific extension of metadata
list of xs:anyURI is problematic for some tools (could use QName I
guess)
Substantial change to existing specifications; granularity of
expression forces lots of wsdl and xsd changes
No ability to have metadata on XML Schema attribute
Not sure how to add metadata for components that are not reflected in
WSDL or xsd
Need to detail separate document structure for metadata
Separate metadata document that is related to the portType
Define a separate metadata document that has composition and separate
lifetime from WSDL. Allow
connection to metadata document through portType open attributes (QName and
location ala wsdlLocation) for
design time introspection. Alloc connection to implementation specific
metadata through resourceProperty
element or MetadataExchange or both for runtime introspection.
<element name="pt1ResourceProperties">
<complexType>
<sequence>
<element ref="type1" minOccurs="0" maxOccurs="1"/>
<element ref="type2" minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
</element>
<element name="type1" type="xs:string"/>
<element name="type2" type="xs:string"/>
<portType name="pt1" wsrp:ResourceProperties="pt1ResourceProperties"
xxx:metadataDescriptor="tns1:pt1MetadataDocument"
xxx:metadataDescriptorLocation="
http://example.com/md/pt1
http://example.com/md/pt1.md";>
<operation name="GetResourceProperty" />
<input name="GetResourcePropertyRequest"
message="wsrp:GetResourcePropertyRequest" />
<output name="GetResourcePropertyResponse"
message="wsrp:GetResourcePropertyResponse" />
<fault name="ResourceUnknownFault"
message="wsrp:ResourceUnknownFault" />
<fault name="InvalidResourcePropertyQNameFault"
message="wsrp:InvalidResourcePropertyQNameFault" />
</operation>
</portType>
The metadata description document would be structured something like below.
It could allow
for non-WSDL component metadata, as well as specialization and
reconcilation.
<Definitions
xmlns=”http://www.proposedstandards.org/xmlns/MetadataDescriptor”
xmlns:tns=”http://example.com/ns/pt1”
targetNamespace=”http://example.com/ns/pt1”>
<MetadataDescriptor
name=”pt1MetadataDescriptor”
interface=”tns:pt1”
wsdlLocation=”http://example.com/ns/pt1
http://example.com/wsdl/pt1.wsdl” >
<Property path=”tns:type1”
mutability=”constant”
modifiability=”read-only” />
<Property path=”tns:type2”
mutability=”constant”
modifiability=”read-only” />
</MetadataDescriptor>
</Definitions>
Pros:
Metadata in a separate document
URI dereferencing is clear (follows wsdlLocation model)
Roles of authorship are clear and separated
Metadata is namespaced and in a single place
WSDL tooling and xml tooling minimal impact
Allows implementation specific extensions of metadata
No change to existing specifications
Metadata on attributes should be no problem
Cons:
New mechanism
New specification
Need to detail separate document structure for metadata
Issue WSRF10: Need mechanism to express metadata on properties such as
‘read-only’
It is currently not possible to determine property behavior based on
examining a property document schema. OGSI ServiceData defined some
metadata for properties to express behaviors such as ‘read-only’. It is
useful to a client to have access to this and similar metadata about a
property.
Discussion occurred at the face-to-face July 27, 2004 about this issue. It
was generally accepted that there is a need to express meta-data about
properties.
Specifications
· WS-ResourceProperties, Version 1.1, March 5, 2004
Notes
Proposed Recommendations
One possible solution is to use the annotation element from schema to add
meta-data about the property.
Another possible solution is to have a secondary document that includes
meta-data about some or all of the properties in a resource property
document.
Some interesting resource property meta-data includes:
§ Insertable:bool
§ Updateable: bool
§ Deleteable: bool
§ Readable: bool
§ Initial Value(s): <any>
§ Constant: bool
§ ValidValue: <any> (??)
Concrete proposals to be sent to the list.
Status: Open since April 28, 2004
Contact: Bryan Murray
Cross Reference:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]