[Rets-dev] Search responses and StandardNames

[Paul Stusiak]

In-line

Scott Gifford wrote:
> A few more things.  First, I should clarify that I'm writing the
> server side of things, not the client, if that makes a difference.
>
>   
As Keith pointed out it does make a difference. Servers generally need 
to implement more stuff than clients.

> I'm also unclear about what the appropriate StandardNames are for some
> elements.  In the specs for RETS 1.5, Table 11-6 says "StandardName -
> Alphanumeric - The name of the field as it is known in the Real Estate
> Transaction XML DTD".  But some elements in the DTD are ambiguous on
> their own, for example "Area", which appears under both LivingArea and
> LotSize.  The file "retsdatadictionary200408.pdf" from the RETS Web
> site seems to resolve some of these, but not all, and it contains many
> StandardNames that seem to be different than those in the DTD, for
> example "School.Primary" instead of "ElementarySchool", and is missing
> others, such as "ListingID".  What is the definitive source of
> StandardNames, and how should these ambiguities be resolved?
>
>   
Those sound like errors in the specification. I'll look into that.

> Somebody suggested to me that I should ignore StandardNames and the
> STANDARD-XML response type altogether, since it's tricky and not
> widely used, and just support COMPACT responses with System Names.  Is
> there rough consensus that's the right way to go?
>
>   

That depends.

If you are a client, there has been a disappointing lack of effort on 
mapping system names to standard names and you almost have to use one of 
the COMPACT or COMPACT-DECODED response formats. I understand the 
reasons behind this - it costs money and we - the RETS community - have 
not done a good job of communicating the value to the folks who pay the 
bills. As a result, we get the bare minimum required to pass compliance. 
There has also been an effort to identify a base set of fields that 
vendors all can agree will return real data - Mapped Standard Names. It 
has been moribund for a while, but we should try again to push this 
effort forward.

If you are a server vendor, as Keith points out, you must support it.

There has also been a request in the Compliance work group to increase 
the thoroughness of the compliance test. Standard-XML is one of the 
areas that will be worked on this year. So, you are on notice.

I'm thinking that whomever suggested that using the Standard-XML 
response type is tricky should have their programming merit badge 
revoked. It isn't.

> Also, are there recommendations for a simple client for testing the
> basics of my server application?  I'm not really ready to do any
> serious testing yet, I'd just like to make sure I'm handling all of
> the basics correctly.  I took a look at the reference client, but it
> looks like a big project to get it all set up.  What do other people
> do for basic testing?  I'm using Linux, but I have a Windows machine
> available for testing if that's helpful.
>
>   

You've had a couple of good suggestions from Keith and Paula. You may 
also want to consider the MRIS Conduit tool. This is more of a 
data-puller tool, but it grew out of the internal test tool. It is a 
Java client so it should run very well on your Linux box, but you'll 
need to use the Windows box to install it - last time I looked it only 
had a Windows exe installer.

The location is http://www.mris.com/products/conduit/

Registration is required, but it is only for internal tracking purposes.

You may also want to install something like qdpf
http://www.hawksley.net/software/qdpf/
It is a trivial Java-based port forwarder that echoes the http 
information to a console window. You could, of course, use something 
more sophisticated like WireShark
http://www.wireshark.org (was ethereal).

You'll definitely find it useful for figuring out what is going across 
the wire.

Paul

> Thanks,
>
> ---Scott.
>
>   
>
[snip]