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