[Rets-dev] RE: Rets-dev Digest, Vol 21, Issue 27

[Eduardo Angeles]

Hi all,

With regards to the JSON idea, I think it would be an interesting topic to discuss on our upcoming RETS meeting.
Also, maybe go a bit further and wrap the JSON-formatted text in a multi-line comment (/*...*/) and then ask the receiving party to unwrap it before parsing it (or doing the eval); this just to prevent a Cross-site request forgery, which might hardly ever happen, but one can never be too sure.

Of course, if we adopt the https:// (SSL) as part of the RETS2.0 security, as they were discussing in the Security group during the last Austin meeting, then perhaps there wouldn't be any need for wrapping JSON (?)

-----Original Message-----
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On Behalf Of rets-dev-request at rets.org
Sent: Saturday, April 28, 2007 9:00 AM
To: rets-dev at rets.org
Subject: Rets-dev Digest, Vol 21, Issue 27

Send Rets-dev mailing list submissions to
	rets-dev at rets.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.rets.org/mailman/listinfo/rets-dev
or, via email, send a message with subject or body 'help' to
	rets-dev-request at rets.org

You can reach the person managing the list at
	rets-dev-owner at rets.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rets-dev digest..."


Today's Topics:

   1. RE: *SPAM* Re: [Rets-dev] Email validation regular expression
      (Matt Lavallee)


----------------------------------------------------------------------

Message: 1
Date: Fri, 27 Apr 2007 12:36:45 -0500
From: "Matt Lavallee" <matt at pmptechnology.com>
Subject: RE: *SPAM* Re: [Rets-dev] Email validation regular expression
To: <jbrush at ronintech.org>
Cc: Rets-dev at rets.org
Message-ID: <00a901c788f2$a024add0$e06e0970$@com>
Content-Type: text/plain;	charset="Windows-1252"

On Friday, April 27, 2007 at 10:01 AM, Jeffery Brush wrote:

> This solution parallels the thinking behind the HTML 4.01
> transitional/strict DTDs.

Not a coincidence. :)

> This way organizations such as regional repositories could
> require the strict formats for input should they choose. Of
> course, the definition of transitional formats should take
> priority as that immediately helps the larger community.

Exactly: This way we could *always* rely on the base schema being implemented!

> As for your JSON idea, RETS2 was designed to be very flexible
> about it's output format. There are toolkits to easily
> convert XML to JSON and back again if both the MLS and the
> client agree to support it. The RETS2 metadata output format
> can easily advertise that an XML format is supported as JSON.

I don't think it was "designed" to be flexible, but an incidental attribute
inherent to XML.  I would far prefer to see industry adoption (hint, hint, MLS
vendors!) of a native JSON export versus an alternative "compact XML" format (as
has thusfar been discussed).

-Matt




------------------------------

_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev


End of Rets-dev Digest, Vol 21, Issue 27
****************************************