[Rets-dev] RQL, Draft 4

[Dave Scott]

> I think this is a problem that needs solving on a standard by
> standard basis.  Do you really need to get bulk search results
> in MISMO format, with complex queries?  Retrieving a specific
> listing in a different output format is one thing, but the day
> to day listing searches are going to be done with RETS payload.

Taking this approach probably guarantees that the RETS transport will  
be confined to RETS payloads.

> Maybe I'm wrong... but if OSCRE is suitable for searching and
> bulk transfer won't it have its own query language?

The OSCRE CIE Listings standard defines the data layer, not the  
message layer.  OSCRE may propose a message layer at a later date;  
but the intent is that the data layer will be separable from the  
message layer (and transport layer) and, so, usable in other contexts  
-- e.g., potentially in a RETS context.

> As has been discussed, the syntax is probably extensible enough to
> support xpath like expressions, which should be enough if we have
> to, but I'd much rather burn that bridge when there's a business
> case for it.

I agree that is one way to go.  There are also more SQL-like ways to  
extend the query language available in the literature.  Also, the  
requirement that RETS 2.0 be a generic transport did not originate  
with me; it's in the RETS 2.0 documents, and in presentations by RETS  
representatives, and in postings on this list.

> As far as using XSLT for custom transforms, I'd rather not tie
> RETS to that spec.  I doubt most people here would be interested
> in implementing MISMO by outputing standard names and then trying
> to write XSLT to rewrite the doc.  If that were reasonable,
> we wouldn't need custom output payloads on the server at all.

I didn't intend to propose integrating RQL and XSLT.  I guess you  
could do that; but I personally would never endorse that approach.

I see where you got the idea that I that I suggested integrating two:
>> If XSL is used to indicate what format is being used in the messages

Sorry, that was a typo.  I meant XSD, which, looking at again, you  
probably can tell from context.

Dave

On Mar 31, 2006, at 5:37 PM, dbt wrote:

> On Thu, Mar 30, 2006 at 05:41:09PM -0600, Dave Scott wrote:
>> If XSL is used to indicate what format is being used in the messages
>> (as I saw in a Verba document), then the payload and the vocabulary
>> are coupled.  Some canonical way of turning hierarchical addresses
>> into Standard Names style designations could be added to the
>> standard.  Such a strategy would not be sufficient by itself to take
>> care of querying hierarchical data.  Because of it's structure, you
>> can flatten RETS Standard XML to guarantee a unique name for each
>> element.  This can't be done for all XML data formats (OSCRE, MITS,
>> and MISMO, e.g.)  You would also need some way in RQL to express
>> hierarchical relations.
>
> I think this is a problem that needs solving on a standard by
> standard basis.  Do you really need to get bulk search results
> in MISMO format, with complex queries?  Retrieving a specific
> listing in a different output format is one thing, but the day
> to day listing searches are going to be done with RETS payload.
>
> Maybe I'm wrong... but if OSCRE is suitable for searching and
> bulk transfer won't it have its own query language?
>
> As has been discussed, the syntax is probably extensible enough to
> support xpath like expressions, which should be enough if we have
> to, but I'd much rather burn that bridge when there's a business
> case for it.
>
> As far as using XSLT for custom transforms, I'd rather not tie
> RETS to that spec.  I doubt most people here would be interested
> in implementing MISMO by outputing standard names and then trying
> to write XSLT to rewrite the doc.  If that were reasonable,
> we wouldn't need custom output payloads on the server at all.
>
> -dbt
> _______________________________________________
> Rets-dev mailing list
> Rets-dev at rets.org
> http://lists.rets.org/mailman/listinfo/rets-dev