OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]