[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Questions from Jeff Larson @ Waveset
Folks,
JeffL from Waveset is not able to post to the list right now. Yes I’m getting that fixed, but in the mean time Jeff wanted to get these observations out onto the list for discussion before Mondays con-call.
===========================
I've recently been fleshing out our SPML support, which among other things includes a Java memory model for SPML requests and responses. This brought up a few relatively minor issues with the specification that I'd like to discuss. This is based on version 10 of the request schema and version 12 of the core schema.
1) The CancelRequest and StatusRequest types do not extend SpmlRequest and therefore cannot have operational attributes. While it may not make sense for these to have "execution" or "requestId" attributes, it does make sense for them to have operational attributes.
I suggest having these extend SpmlRequest. If we want to be pedantic we could add restrictions for the attributes or factor out another intermediate "supertype". But personally I'm fine with spec annotations that indicate that attributes may be ignored in some cases.
2) CancelResponse and StatusResponse also do not extend SpmlResponse, though they do allow errorMessages. There may be reasons for these to have operational attributes, and I could imagine them using the "results" and "error" attributes in the same way as other requests. These feel more like direct extensions of SpmlResponse.
3) The SpmlResponse attribute "results" being plural implies that there is more than one thing in its value. This is inconsistent with the type ResultCode which is singular. Suggest renaming this to "result" which is also then consistent with "error".
4) The BatchRequest model uses xsd:sequence, which will require that request elements follow the order: modify, add, delete, extended. In general I dislike enforced order unless it serves some purpose. For batches, the application may need to specify operations in a certain order, for example don't create a new account until you can delete an existing one.
I suggest changing this to allow random order of the elements within the BatchRequest. This is less of an issue for other sequences, for example SearchRequest. But again, I find sequence to be useful only for "document" XML or for extremely high transaction rate systems that may be able to use sequence to improve parsing performance. Neither apply here.
The same issue applies to BatchResponse.
5) This is more a question than an issue, but what was the intended purpose for batchAttributes? How would these differ from operational attributes of the batch?
6) In ExtendedResponse, Attributes is "unbounded". Since <attributes> already contains an unbounded list of <attr>s, shouldn't Attributes be maxOccurs=1?
Thank you for your time, Jeff Larson Waveset
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]