RE: [provision] Liberty Identity Personal Profile example...

["Jeff Bohren" <jbohren@opennetwork.com>]

Gerry,

To be precise, the example I posted shows how SPML could be used to
provision the data that could also be represented by the below XML
document. That is a subtle, but important difference. As a provisioning
protocol the XML document does not serve very well, as indicated in the
Liberty spec itself.

Provisioning this information is not as simple as just consuming a WSDL
file and generating a stub. For instance in the Liberty ID-WSF Data
Serice Template
(http://www.projectliberty.org/specs/draft-lib-svc-dst-v1.0-16.pdf) line
706 the XML to replace a Postal Address is:

<Modify>
  <Resource> 
    <saml:NameIdentifier>d8ddw6dd7m28v628</saml:NameIdentifier> 
  </Resource> 
  <Modification overrideAllowed="True"> 
 
<Select>/IDPP/IDPPAddressCard[IDPPAddressType='urn:liberty:idpp:addrType
:home']</Select> 
    <NewData> 
      <IDPPAddressCard id='98123'> 
        <IDPPAddressType>urn:liberty:idpp:addrType:home<IDPPAddressType>

        <Address> 
          <PostalAddress>c/o Carolyn Lewis$2378 Madrona Beach
Way</PostalAddress> 
          <PostalCode>98503-2342</PostalCode> 
          <L>Olympia</L> 
          <ST>wa</ST> 
          <C>us</C> 
        </Address> 
      </IDPPAddressCard> 
    </NewData> 
  </Modification> 
</Modify> 

Note that there logic involved that would not be represented in a WSDL
file. Further note that this  can not be safely used to modify the
postal address anyway. Line 701 reads:

"Following example replaces current home address with a new home address
in the personal profile of a Principal. Please note that this request
will fail, if there are two or more home addresses in the profile,
because it is not clear in this request, which out of those addressed
should be replaced by this address."

The SPML approach can safely modify any of the profile data structures
because each sub element can be uniquely identified.



Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 


-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com] 
Sent: Thursday, July 31, 2003 2:39 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] Liberty Identity Personal Profile example... 






These examples show how the SPML might communicate this XML document::

  <InformalName>theWanderer</InformalName>
  <CommonName>
    <CN>Zita Lopes</CN>
    <AltCN>Maria Lopes</AltCN>
  </CommonName>
  <LegalIdentity>
    <LegalName>Zita Maria Oliveira da Figueira Lopes</LegalName>
    <VAT>502677123</VAT>
  <LegalIdentity>

I urge the committee members to examine the documents that Jeff has
worked up and consider them against this and in the light of previous
issues raised on this list.  Some important points to consider in my
view are:

1. The examples introduce a naming system to relate hierarchical
elements that are naturally related in the simple XML document.  This
naming system exists only for the benefit of the SPML and is not present
in the target document. 2. The examples force the implementor to perform
a quite complex mapping of request structures to the XML document 3.
It's still not clear how attributes (as opposed to elements) in the
target document are conveyed clearly in the SPML 4. The sheer complexity
of the SPML approach

And there are additional problems associated with the schema.  We have
not yet seen how an SPML schema might look for these documents but there
is some form of mapping required to transform the schema from XML Schema
to SPML schema.  Also, if I use the native Liberty XML Schema as
published, I can use tools such as XMLSpy to analyse, validate or create
instance documents whereas with the SPML schema I have no such tool
support.  I can include or reference the XML Schema in a WSDL document
verbatim to allow consumers to generate client libraries to talk to my
service.  These tools are not available for SPML schema.

These examples illustrate to me that there is a very large penalty to
pay with the SPML.  The hoops that implementors of the SPML will have to
jump through to communicate a simple XML document represent the tip of
the iceberg.  Along with the document transformations are schema
transformations and the inability to use off-the-shelf tools.  The fact
that schemas and documents published by almost all Web Services and
toolkits available today will need these complex transformations to be
used with the SPML at all is a fundamental problem.

There are still unanswered questions about aspects of this problem, but
without going any deeper into this argument it seems to me that the SPML
approach must be viewed as an unsatisfactory solution.  I will certainly
not stand in front of my management, technical review boards, and
ultimately IBM customers, and suggest that this is the best way to
communicate their XML data and provide access to their Web Services.