[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Fw: SPML Roadmap
Rami,
I don't think that what you are suggesting is practical within the context
of the current SPML. Here's a few of the reasons why:
1. You still have not identified which schema element in the referenced
schema represents your type - a schema document may contain many type
definitions.
2. XML Schema instance documents cannot be transported in a DSML attribute
value as you have shown because DSML attribute values may only be strings
which precludes the use of raw XML. You would instead have to escape it so
your example:
...
<attribute name="XMLData">
<value>
<simplepersonprofile xmlns:xsi="http://www.vocoder.org/XMLSchema">
<firstname>Mr</firstname>
<lastname>Wakeman</lastname>
<residence>
<address>6th street</address>
<city>Austin</city>
<country>Texas</country>
<state>United States</state>
</residence>
<jobhistory>
<title>marketing manager</title>
<date>January 2002</quantity>
<manager>Dan Becker</price>
<description>Let’s party</price>
</jobhistory>
</simplepersonprofile >
</value>
</attribute>
...
Now becomes:
...
<attribute name="XMLData">
<value>
<simplepersonprofile
xmlns:xsi="http://www.vocoder.org/XMLSchema">
<firstname>Mr</firstname>
<lastname>Wakeman</lastname>
<residence>
<address>6th street</address>
<city>Austin</city>
<country>Texas</country>
<state>United States</state>
</residence>
<jobhistory>
<title>marketing manager</title>
<date>January 2002</quantity>
<manager>Dan Becker</price>
<description>Let’s party</price>
</jobhistory>
</simplepersonprofile >
</value>
</attribute>
...
This is more than a simple aesthetic problem. For one, you have introduced
the overhead of encoding and decoding what could turn out to be a large
document. Secondly, the receiver of this document, because the content is
no longer XML, must perform an additional parse operation. Also, because
the profile is no longer an XML document, it cannot be processed by common
XML processing tools such as XSLT. And I'm sure I've overlooked other
difficulties.
3. How do I go about changing Mr Wakeman's residence? The answer of course
is that I cannot because I must replace the whole attribute value.
May I suggest that if the SPML is to use XML Schema then we consider what
it would take to offer full support for it and for other XML-based schema
languages. In my view, this is not something that can just be bolted on as
an afterthought.
Gerry
|---------+---------------------------->
| | "Elron, Rami" |
| | <rami_elron@bmc.c|
| | om> |
| | |
| | 07/24/2003 08:25 |
| | AM |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Gearard Woods/Irvine/IBM@IBMUS |
| cc: provision@lists.oasis-open.org, "Elron, Rami" <rami_elron@bmc.com>, "Cohen, Doron" <Doron_Cohen@bmc.com> |
| Subject: RE: [provision] Fw: SPML Roadmap |
>------------------------------------------------------------------------------------------------------------------------------|
Gerry,
The attached document includes some examples that elaborate on my previous
note.
Best regards,
Rami.
---------
Rami Elron
Senior System Architect
Security Business Unit
BMC Software Ltd.
Tel: 972 3 766 2434
Fax: 972 3 645 1100
Mobile: 972 64 286 434
email: rami_elron@bmc.com
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thursday, July 24, 2003 2:00 AM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: RE: [provision] Fw: SPML Roadmap
Not to be picky, but which venues would those be? I can't imagine that
what you are proposing emerged from any previous discussion as an ideal
solution, particularly in a world where we are no longer constrained by an
attribute/value model. I also don't understand why you are assuming that
this is only relevant to accounts. I'm suggesting this scenario because of
the schema used at the interop where a very simple set of user information
was provisioned. Based on that, I thought it would be instructive if a
more real-world example was examined and so I suggested the Liberty user
profile.
Let's talk about containment. LDAP/DSMLv2/SPML support containment, or the
illusion of containment, through the use of a hierarchical naming system.
Without using such a hierarchical naming system how do I express the kind
of containment that you are demanding? Let's paraphrase your solution in
pseudo-SPML:
<batchRequest>
<addRequest>
<identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID">
<<< ???? What goes here???? >>>
</identifier>
<attributes>
<attribute name="objectclass">
<value>IDPPType</value>
</attribute>
<attribute name="InformalName">
<value>Johnny</value>
</attribute>
</attributes>
</addRequest>
<addRequest>
<identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID">
<<< ???? What goes here???? >>>
</identifier>
<attributes>
<attribute name="objectclass">
<value>CommonNameType</value>
</attribute>
<attribute name="CN">
<value>John Smith</value>
</attribute>
</attributes>
</addRequest>
<addRequest>
<identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID">
<<< ???? What goes here???? >>>
</identifier>
<attribute name="objectclass">
<value>AnalyzedNameType</value>
</attribute>
<attribute name="PersonalTitle">
<value>Sir</value>
</attribute>
<attribute name="nameScheme">
<value>urn:x:y:z:1.0</value>
</attribute>
</attributes>
</addRequest>
...
</batchRequest>
There are all kinds of other issues with this including the fact that there
can be any number of levels in this hierarchy, each one requiring an add,
but importantly:
1. The relationships here are those that you outlined: the IDPPType
instance has a common name which in turn has an analyzed name. What
identifiers do I use to indicate containment? Am I forced to use DNs or
some other hierarchical naming system?
2. If the identifiers are not used to express containment, how do I
associate them?
3. How do I describe or impose the constraint that there may only be 10
informal names for example?
4. How do I convert back and forth between the instances described in XML
Schema and those described in SPML schema? It seems that now there is a
requirement that I maintain state and mapping information for each profile
and any constituent objects. I'm effectively forced to maintain two data
models and map between them outside the service that is using the actual
data.
5. You have indicated that, for the schema mapping, there is an implicit
set of rules. Contained types that are primitives, such as a string,
become SPML attribute types, while those that have a cardinality are
contained. What about XML Schema attribute definitions such as nameScheme?
How do convert those and how do I distinguish between attributes and
elements in an SPML add request, for example, when doing conversions
to/from the real profile? Where did these schema mapping rules come from
and is there, or will there be, a normative set?
Not to mention that now I have to send something resembling what I just
outlined, and suffer through all kinds of compromises and conversions, to
communicate:
...
<InformalName>Johnny</InformalName>
<CommonName>
<CN>John Smith</CN>
<AnalyzedName nameScheme="urn:x:y:z:1.0">
<PersonalTitle>Sir</PersonalTitle>
</AnalyzedName>
</CommonName>
...
Your dismissive tone here is frustrating not only because you seem to be
avoiding getting into any real depth on this issue and appear to be
minimizing what is a very real problem, but also because you are implying
that this concern is due to ignorance of some previous discussions in some
other venue, that incidentally cannot be mentioned. In actual fact an
attribute/value model is an extreme compromise. So, rather than dismissing
the question, if you could provide actual XML, or update what I've
presented here, or indeed provide a real example of one of the other
"several ways to do the same thing" and then allow open and full discussion
of the issues and compromises then I think we could start making progress,
one way or the other.
By the way, I'd still like to know if Rami's suggestion is true. Is the
PSTC going to allow XML Schema to be referenced? If this is true then the
data and operation model will not hold and it seems to me that the
approach so far will require significant rework.
Gerry
|---------+---------------------------->
| | "Jeff Bohren" |
| | <jbohren@opennetw|
| | ork.com> |
| | |
| | 07/23/2003 02:01 |
| | PM |
|---------+---------------------------->
>---------------------------------------------------------------------------
---------------------------------------------------|
|
|
| To: <provision@lists.oasis-open.org>
|
| cc:
|
| Subject: RE: [provision] Fw: SPML Roadmap
|
>---------------------------------------------------------------------------
---------------------------------------------------|
As Rami notes there are several ways to solve the issue representing of
complex data types represented in a hierarchical attribute/multi-values
data model. These issues have been so thoroughly discussed in other
venues that I won't repeated them here.
SPML is not limited to managing accounts. It can also be used to manage
other types of objects such as groups, organizations, etc. It can also
be used to manage objects that are contained by other objects, which is
one way to represent complex data types.
One approach that would work for the Liberty Personal Identity Profile
would be to represent the core profile in one object and then have
contained objects for each of the complex data types. For instance there
would be an InformalName attribute on the profile object but the list of
CommonName objects would be represented as contained instances of a
common name object. Likewise the common name object would have a CN
attribute but the list of AnnalyzedName objects would represented as
contained instances of analyzed named objects.
You could then create, modify, or delete all of the relavent objects in
a single SPML Batch Request.
Again there are several ways to do the same thing.
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Wednesday, July 23, 2003 4:10 PM
To: provision@lists.oasis-open.org
Subject: [provision] Fw: SPML Roadmap
----- Forwarded by Gearard Woods/Irvine/IBM on 07/23/2003 01:10 PM -----
|---------+---------------------------->
| | Gearard Woods |
| | |
| | 07/23/2003 10:48 |
| | AM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: "Elron, Rami" <rami_elron@bmc.com>
|
| cc: provision@lists.oasis-open.org, "Elron, Rami"
<rami_elron@bmc.com> |
| From: Gearard Woods/Irvine/IBM@IBMUS
|
| Subject: RE: SPML Roadmap (Document link: Gearard Woods)
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Rami,
Thanks for the document. I'm afraid that it doesn't address my concerns
though and I think you might be underestimating the coupling between the
schema and the data model. If you are suggesting that an XML Schema
document could be referenced by an SPML schema, then the SPML is obliged
to allow instances of structures defined in that schema to be
transported. Let's remain with the Liberty user profile and get very
specific about what the schema would look like and how the schema
impacts the data model. To extend your example, I imagine that you are
suggesting that the Liberty schema be referenced like this:
<schema>
<objectClassDefinition name="LibertyPersonalProfile">
<superiorClasses>
<objectClassDefinitionReference name="Complex">
<schemaIdentifier
schemaIDType="urn:oasis:names:tc:SPML:1:0#GenericString">
<schemaID>http://www.projectliberty.org/specs/lib-svc-id-pp.xsd</schemaI
D>
</schemaIdentifier>
</objectClassDefinitionReference>
</superiorClasses>
</objectClassDefinition>
</schema>
This raises a number of questions:
1. How is the element inside the schema document identified? I'm
interested only in the IDPP element. I disagree with the suggestion
that specific names be reserved by the way, this seems cumbersome and
esentially turns the name into something else. 2. Imagining that I do
identify the portion of the schema that I'm interested in, how do I use
it? In your document you say that "While the definition may seem to
imply reliance on a simple attribute/value model, it can actually
leverage this very model to take advantage of much more complex data
structures." If this is true, what would the add request look like based
on the external schema? What about a modify request? These both require
an attribute/value model so I'm having some difficulty understanding how
the XML Schema would relate to the actual request data. If you could
show me specifically what the request XML would look like in both cases
I'd be obliged. 3. If the SPML really can actually consume XML Schema,
why define a separate, SPML-specific, schema language? Gerry
|---------+---------------------------->
| | "Elron, Rami" |
| | <rami_elron@bmc.c|
| | om> |
| | |
| | 07/23/2003 08:51 |
| | AM |
|---------+---------------------------->
>-----------------------------------------------------------------------
-------------------------------------------------------|
|
|
| To: Gearard Woods/Irvine/IBM@IBMUS,
provision@lists.oasis-open.org
|
| cc: "Elron, Rami" <rami_elron@bmc.com>
|
| Subject: RE: SPML Roadmap
|
>-----------------------------------------------------------------------
-------------------------------------------------------|
Hi Gerry,
The attached document addresses and hopefully answers your concerns. If
you have any further questions or remarks regarding this document or the
roadmap document, please do not hesitate to call me.
Best regards,
Rami.
------------------------------------------------------------------------
----
---------
Rami Elron
Senior System Architect
Security Business Unit
BMC Software Ltd.
Tel: 972 3 766 2434
Fax: 972 3 645 1100
Mobile: 972 64 286 434
email: rami_elron@bmc.com
-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Wednesday, July 23, 2003 12:22 AM
To: rami_elron@bmc.com; provision@lists.oasis-open.org
Subject: SPML Roadmap
Rami,
Further to the call yesterday, I wanted to clarify one of the major
problems that I have with the SPML as it stands and to get your feedback
on how the problem might be solved either with today's approach or with
features that are on the roadmap. Fundamentally, I believe that the
schema language introduced by the current SPML is too restrictive and
reflects a data model that will not be able to satisfy my immediate
needs to transport complex XML data. In fact, I have difficulty seeing
how a roadmap built on this schema language can be made to fit my
requirements in the long run. As an example, could you explain to me how
I might use the SPML in the simple scenario where I have a service (a
Web Service) that I wish to provision which requires the user
information to be provided using the Liberty Alliance user profile
(http://www.projectliberty.org/specs/lib-svc-id-pp.xsd)? This is not an
outlandish scenario by any means, and you could substitute other user
representations such the ebXML UserType for example. Obviously, since
the SPML cannot support XML Schema, I have to think that publishing the
schema for such a service might be problematic. It also seems
difficult, given the attribute/value data model in the current SPML, to
communicate an instance of one of these structures. If you can reassure
me that this is in fact quite seamless and simple in the current SPML,
or your roadmap answers this concern, I would be very grateful.
Thanks,
Gerry
#### Response to SPML Roadmap concerns.doc has been removed from this
note on July 23, 2003 by Gearard Woods
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
kgroup.php
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro
up.php
You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro
up.php
#### Response to SPML Roadmap concerns - more.doc has been removed from
this note on July 24, 2003 by Gearard Woods
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]