[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Outstanding technical issues
The ability to perform large searches is critical and the mechanism should be made clear. Because the paged search control is not part of the LDAP specification doesn't really justify leaving this important feature out of the SPML completely, particularly when it's not obvious how it would be done in a consistent manner. It would at least be reassuring to see how a standard schema would address this. The use of xml:lang is one aspect of the internationalization problem, and this should be in the schema. The ability to return multiple error messages is another. If the schema does not allow these things then there is simply no way to communicate the information, negotiate as you will. It is not true that the locale is always obvious and always singular. There are many cases where the locale of the system performing an operation is different from the locale of the system requesting the operation which is different again from the locale of the user who initiated the operation. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/21/2003 09:14 | | | AM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: "Darran Rolls" <Darran.Rolls@waveset.com>, Gearard Woods/Irvine/IBM@IBMUS, <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Outstanding technical issues | | | >------------------------------------------------------------------------------------------------------------------------------| For the same reasons that LDAP search controls are not part of the core LDAP specification, I don't think this need to be part of the core SPML specification. Instead we should address this when we address standard schemas. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Darran Rolls [mailto:Darran.Rolls@waveset.com] Sent: Friday, March 21, 2003 11:21 AM To: Jeff Bohren; Gearard Woods; provision@lists.oasis-open.org Subject: RE: [provision] Outstanding technical issues 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]