Hi Ian:
A concern with this approach is that
it works only if the person responsible for the meta-data values also has
access to the XSD declaration. Frequently, the XSD schema is "fixed"
by some organization (such as a standards body) and is not available to
decorate in this way.
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Springer, Ian P." <>
wrote on 09/21/2004 12:59:50 PM:
> Hi Tom,
>
> A fourth possiblity is defining the metadata as fixed attributes in
the resource
> properties document schema. The WS-RP spec schema would define the
available
> metadata attributes as follows:
>
> <attribute name="readable" type="xsd:boolean"
form="qualified" />
> <attribute name="writeable" type="xsd:boolean"
form="qualified" />
> <attribute name="deleteable" type="xsd:boolean"
form="qualified" />
>
> etc...
>
> Then, in the resource properties document schema, metadata attributes
would be
> specified as follows:
>
>
> <xsd:import namespace="http://www.ibm.com/xmlns/stdwip/web-services/WS-
> ResourceProperties"
> schemaLocation="../spec/wsrf/WS-ResourceProperties-1_1.xsd"
/>
>
> <element name="BlockSize">
> <complexType><simpleContent>
> <extension base="xsd:int">
> <attribute ref="wsrp:writeable"
fixed="false" />
> <attribute ref="wsrp:deleteable"
fixed="false" />
> </extension>
> </simpleContent></complexType>
> </element>
>
> <element name="Manufacturer">
> <complexType><simpleContent>
> <extension base="xsd:string">
> <attribute ref="wsrp:writeable"
fixed="false" />
> <attribute ref="wsrp:deleteable"
fixed="false" />
> </extension>
> </simpleContent></complexType>
> </element>
>
> etc...
>
>
>
> --Ian
>
> | -----Original Message-----
> | From: Tom Maguire [mailto:]
> | Sent: Tuesday, September 21, 2004 10:12 AM
> | To: Tom Maguire
> | Cc:
> | Subject: Re: [wsrf] Issue 10: Concrete proposals for Metadata
> | (Action Item)
> |
> |
> |
> |
> |
> | Perhaps I was a bit too subtle with the analysis of potential
> | resolutions
> | and what I believe
> | is the preferred proposal. The 3 choices are:
> |
> | 1) Add metadata to portType in annotations
> | 2) Add metadata to portType through attachments (ala policy
> | attachments)
> | 3) Separate metadata document that is related to the portType
> |
> | The pros and cons of each choice are detailed below. The
> | conclusion I draw
> | is
> | that choice 3 met most of the requirements and had the most
> | desirable set
> | of attributes.
> |
> | This choice would likely require our adding another
> | specification to the
> | WSRF suite
> | of specifications and deliverables.
> |
> | Thoughts?
> |
> | Tom
> |
> | Tom Maguire/Hawthorne/IBM@IBMUS wrote on 09/17/2004 03:46:26 PM:
> |
> | >
> | >
> | >
> | >
> | > 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:
> | >
> | >
> |
