uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [uddi-spec] Use of maxRows and listHead in V3
- From: "Daniel Feygin" <feygin@unitspace.com>
- To: "'Rogers, Tony'" <Tony.Rogers@ca.com>
- Date: Thu, 12 Aug 2004 12:03:24 +0400
Tony,
What is that case for returning zero results?
Obviously one where you don't really care what the results are. Sounds
like the only application of that would be some form of debugging, but not an
actual customer scenario. Therefore I suggest maxRows = 0 be treated
the same as maxRows < 0. I am not particularly attached to this
though.
More importantly, ignoring invalid values in both maxRows
and listHead might cause unintended runtime behavior of a UDDI client due to
programming error, which would have been identified early on if the registry
responded with exception. Just as some forms of invalid input cause an
exception due to schema validation, I believe meaningless maxRows and listHead
values should also be rejected with an exception. Being silent about an
erroneous input just delays the resolution of a problem, promoting poor quality
of UDDI clients. I know I should have raised this issue when CR-6 was
proposed, but it somehow didn't catch my attention then.
Daniel
OK, Andrew - you've said that at least three times (on my
e-mail, anyway), but you still haven't addressed Daniel's question about
maxrows. It's a good question, too.
I'd suggest that negative values be ignored (return all
values, or node maximum), but the big question is zero - there could be a case
for returning zero results, but providing (in the list description element) the
number of results - I don't think this would break the result structures,
because they are able to return zero results.
Sounds like it's worth raising a change request for the
maxrows = 0 case.
Change request 6 added text to
clarify this and it was included in v3.0.1.
Extend section 5.1.5 as follows:
When a listDescription is returned as part of the
result set, it provides a listHead value that
indicates the index position within all matches with
which the returned result list starts. For
example, if the result set returned contains items 1
through 10 of 18, then the listHead would
be 1, or if the current result set contained items
11-18 of 18, then the listHead would be 11.
The optional listHead argument to a find_xx
API MAY be used to force the list returned to start
with a particular element by making further calls.
This is useful when the size of the resultant
list is too large to be returned in a single query.
If a listHead of less than 1 is specified, a value of 1 will be
used to produce the result. If a listHead that exceeds the total
number of results is provided, an empty result set will be returned.
Also in 5.1.9.2, 5.1.10.2, 5.1.11.2, 5.1.12.2,
5.1.13.2 the description of listHead should be changed to:
·
listHead:
This optional integer value is used to indicate which item SHOULD be
returned as the head of the list. The client may request a subset of the
matching data by indicating which item in the resultant set constitutes the
beginning of the returned data. See Section 5.1.5 for a detailed
description of the listHead argument.
Andrew Hately
IBM Software Group,
Emerging Technologies
email: hately@us.ibm.com
phone: (512)
838-2866
"Daniel Feygin"
<feygin@unitspace.com>
08/11/2004 08:15 AM
|
To
| <uddi-spec@lists.oasis-open.org>
|
cc
|
|
Subject
| [uddi-spec] Use of
maxRows and listHead in V3 |
|
It is not clear what a V3 registry is supposed to do when it receives
invalid input in maxRows or listHead attributes that are defined in every find
message. Meaningful values are those greater than 0, but the spec does not
say what the registry must do when maxRows="0" (should an empty list be
returned, should that cause an exception or should that serve as the indication
to apply the default maxRows policy parameter?), when maxRows is a negative
number or when listHead is less than 1. Any xsd:int value would pass
schema validation, so the spec needs to be explicit about registry behavior when
a value less than 1 is provided.
smime.p7s
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]