Hi Tim, Thanks very much for bringing this up. In addition to being generally confusing, it turns out that the allowed values cited for "rant_no" were wrong. I've made some revisions, which I hope clears this up. The new version of the OpenSRS API Specification is posted in the Reseller Resource Center; please see page 195 and let me know if it's still unusable.
Thanks again, Clara Clara Cabral Technical Writer Tucows Inc. 416-535-0123 x1239 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim Woodcock Sent: Tuesday, November 04, 2003 6:41 PM To: Robert L Mathews Cc: [EMAIL PROTECTED] Subject: Re: API Documentation for Process Pending Order 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 [EMAIL PROTECTED] 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/ >
