Correct this was the discussion point at the F2F when the TC came up with
the
three approaches to be considered. Thanks for recalling that Steve.
Tom
Steve Graham/Raleigh/IBM@IBMUS wrote on 09/21/2004 01:20:17 PM:
>
> 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
theavailable
> > 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:
> > | >
> > | >
> > |
