[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Issue 10: Concrete proposals for Metadata (Action Item)
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." <ian.springer@hp.com> 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:tmaguire@us.ibm.com] > > | Sent: Tuesday, September 21, 2004 10:12 AM > > | To: Tom Maguire > > | Cc: wsrf@lists.oasis-open.org > > | 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: > > | > > > | > > > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]