Another example of a conflict:
In the docs for sw_register..
the ca_link_domains description says "used with the rant_no key to link
two .ca domains together." The allowed values for this paramter talk
about the reg_domain, not the rant_no key.
Worse still, if you look at the description for the rant_no key, it says
Description:
An indication of whether to base the domain s contact information on data from
the CIRA whois, or on another dot.ca domain. (Note: To base the domain s
contact information on another dot.ca domain, the ca_link_domain parameter
must be populated.)
Note: If rant_no is specified, any information in ca_link_domain will be
ignored.
Obligation:
Optional Location: This parameter is located within the request associative
array. Allowed Value(s): 0 (or null) or 1. 0 or null = register domain in a new
profile at CIRA, or on another dot.ca domain (via ca_link_domain ); 1 = base
This is utterly confusing.
Does anybody at opensrs READ the documentation? I am guessing not.
This is your business focus guys.
Oh wait. It isn't your business focus anymore. I guess those of us doing
registrations are just second rate now.
With this said, I have to say that you've at least done the work required to
get the bookmarks back in the documentation. That is worth something.
Quite frankly, I think OpenSRS needs to pay a little more attention to its
registration system. There is a lot of good stuff here, but bad marks for
attention to detail.
---------------------------------------------------------------------
Tim Woodcock twoodcock@baremetal.com
BareMetal.com Inc. http://baremetal.com/
Software Development Team
---------------------------------------------------------------------
Message received 2003-11-04 from 'Robert L Mathews':
> On pages 155-159 of the API manual, the description of the API response
> to Process Pending Order could use some work.
>
> First of all, the docs explaining the format of the returned parameters
> don't mention the fact that there are two separate arrays or attributes
> returned, called "rwi_attributes" or "attributes":
>
> $VAR1 = {
> 'rwi_attributes' => {
> 'order_id' => '11554082',
> 'number_of_canceled_orders' => '0'
> },
> 'is_success' => '1',
> 'protocol' => 'XCP',
> 'object' => 'DOMAIN',
> 'attributes' => {
> 'registration expiration date' => undef,
> 'id' => '0',
> 'f_auto_renew' => undef
> },
> 'response_text' => 'Transfer request has been successfully sent...',
> 'response_code' => '200',
> 'action' => 'REPLY'
> };
>
> I'm not sure why there are two separate but similar arrays in the result,
> but anyway, the description for "order_id", for example, should probably
> mention that it's returned in "rwi_attributes", since that's nonstandard.
>
> What's more confusing is that although the Perl response code example
> shows "rwi_attributes" correctly, the "Response Examples (XML)" section
> has the following incorrect example that mixes up the two:
>
> <item_key="attributes> [sic, no closing quotes]
> <dt_assoc>
> <item_key="order_id">3738554</item>
> <item_key="number_of_cancelled_orders">0</item>
> </dt_assoc>
> </item>
>
> That first line should read:
>
> <item_key="rwi_attributes">
>
> Finally, there is no description in the docs of the "id" value in
> "attributes". Perhaps it's the same as the deprecated "transaction_id"?
>
> On a separate but related subject, the latest version of the API
> introduced the "Process Transfer" command to "allow the resubmission of
> failed transfers" from Declined Orders. I don't understand why that's
> needed, since "Process Pending" works just fine for doing that. Perhaps
> someone from OpenSRS can explain what is different about "Process
> Transfer" that should cause people to use it instead of "Process Pending
> Order"?
>
> --
> Robert L Mathews, Tiger Technologies http://www.tigertech.net/
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:50 EDT