RE: [provision] Outstanding technical issues

["Darran Rolls" <Darran.Rolls@waveset.com>]

Re 1.  Does someone want to take a stab at what the operational
attributes will look like to do this?  I propose we then add this to the
seachRequest section of the non-normative text by way or example.

Re 2.  Does anyone disagree?  Shall I add a discussion point for
Monday's meeting?  

=========================================================
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
512) 657 8360                     
=========================================================


-----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com] 
Sent: Friday, March 21, 2003 7:23 AM
To: Darran Rolls; Gearard Woods; provision@lists.oasis-open.org
Subject: RE: [provision] Outstanding technical issues


1- The controls in DSMLv2 are conceptually equivalent to SPML
operational attributes, and as such are redundant. Also, DSMLv2 controls
are really LDAP controls. This makes sense in DSMLv2 which will usually
be back-ended by an LDAP server, but does not make as much sense in
SPML. Also, DSMLv2 controls are BER encoded, which again makes sense in
DSMLv2, but not in SPML.

2- I think this is reasonable. The use of the xml:lang attribute should
be the responsibility of the SPML implementers, as should be what
character sets to use.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 

-----Original Message-----
From: Darran Rolls [mailto:Darran.Rolls@waveset.com] 
Sent: Thursday, March 20, 2003 3:40 PM
To: Gearard Woods; provision@lists.oasis-open.org
Subject: RE: [provision] Outstanding technical issues

Folks

On these two issues:

1- Can someone explain the issues that prompted the removal of these
page controls as we detached from DSMLV2 (apart from simply not
including that schema).  What would be the impact of putting them back?

2- Is it reasonable to say that the lang control of messaging cast into
an SPML exchange is not the responsibility of the protocol but rather
one of relationship and trust establishment between the client and
server?

=========================================================
Darran Rolls                      http://www.waveset.com
Waveset Technologies Inc          drolls@waveset.com 
512) 657 8360                     
=========================================================


-----Original Message-----
From: Gearard Woods [mailto:gewoods@us.ibm.com] 
Sent: Wednesday, March 19, 2003 4:48 PM
To: provision@lists.oasis-open.org
Subject: [provision] Outstanding technical issues





Now that a decision has been reached to continue with the current
proposal,
I'd like to highlight some technical issues that have surfaced over the
past couple of weeks that should be addressed before the spec can be
considered to be viable.  The most significant of these is the ability
to
perform searches which return very large data sets.  With DSMLv2/LDAP,
this
is generally accomplished using a paged search control to "page" through
the result set.  The current SPML has removed controls so this is not
currently an option unless, of course, controls are reintroduced and
then I
imagine there would need to be some form of schema description for
controls.  Large searches are common in our use cases for performing
reconciliation of target data with the provisioning system's version.
Obviously, if all of the target data must be accumulated in memory
before
it can be sent to the client there is a significant scalability problem.

I find it hard to see how it would be accomplished without a major
rework,
but without the ability to communicate complex types I think the spec is
just not practical for widespread use.   We have a number of resources
that
we provision today where, because of our use of DSML, we are obliged to
encode complex data structures in string attribute values.  This is
obviously problematic for a number of reasons.  My opinion is that
continued effort should be directed at this problem and the related
problem
of the schema language, not just for immediate practical reasons but
because this will dictate a lot of the future capabilities of the SPML.

Another issue which has plagued our use of DSMLv2 is in the area of
internationalization.  We touched on this last week, and there are many
approaches to this problem, but DSMLv2 makes it hard and the current
SPML
is no better.  It could be argued that internationalization is not the
focus of a spec like this, but the spec should not prohibit the use of
mechanisms that allow the system as a whole to communicate useful
human-readable information.  In DSML, the inability to return
multi-lingual
error messages is, I think, a weakness.

Gerry