RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:56 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm Here's an odd one. This packet: valuearraydatavaluestructmembernameprop1/namevaluestring val1/string/value/membermembernameprop2/namevaluestringval2 /string/value/member/struct/valuevalueboolean1/boolean/value /data/array/value Through your parser produces two arrays (an outer one with one element and an inner one with the two specified elements). That don't seem right... I'm making the assumption (probably a good one) that the problem is on my end... but I'm stumped as to what it is. Any ideas? What'd I do wrong? Thanks, Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215882 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
I'm making the assumption (probably a good one) that the problem is on my end... Jim: It's not a problem... just confusion brought on by a lack of explanation. That outer array is the array of params... you can safely ignore it. To make things clearer, I added a second CFDUMP that displays the deserialized package by itself. -- Roger Benningfield ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215895 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 10:50 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) I'm making the assumption (probably a good one) that the problem is on my end... Jim: It's not a problem... just confusion brought on by a lack of explanation. That outer array is the array of params... you can safely ignore it. To make things clearer, I added a second CFDUMP that displays the deserialized package by itself. Cool... I like problems that end up not being problems. ;^) I need a lot more testing but so far, so good. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215917 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Mostly because I'd never heard of it until you mentioned it. Where have you been for the past two weeks while I've been ranting about not having something like this. ;^) Jim: I only skim the list, in general. I'm surprised I didn't notice the conversation, though... I have watchlists set up for XML and RSS for CFTalk, since those are the two areas where I'm best positioned to be helpful. I have no idea why they failed in this instance. It does look good - it's just odd that in my posting/searching I never came across it. You were probably one search term away... that's how it always works out for me. Although if it helps, I had an article/CFC published in DRK4 that addresses XML-RPC in CF. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215877 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
But although the system does seem to be well supported it also seems to be poorly documented. ;^) Jim: That's a matter of perspective. Some people love Dave Winer's approach to spec-writing, and some people absolutely *loathe* it. I'm gonna guess you're in the latter group. :D - Convert a null into an empty value: value/value. - Convert a null into an empty string: string/string. - Throw an error. I can't say conclusively, but I would opt for the first or third choice. If you can afford the ambiguity, the first is the best... most implementations (including mine) will interpret an empty value / as a zero-length string, but at least it leaves open the possibility for other implementations. Any idea about what's right? Technically, XML-RPC dates have no timezone. Apps are expected to set timezones in another method, or within another param in the current method. In practice, my (de)serializer respects the above... but the instant it returns the value to my main code, I promptly assume that it is UTC and go from there. :-) +) String formatting seems... odd. The spec claims that only ampersands and less-than signs should be escaped - is this right? Not even greater-than signs? Nothing for control characters? Basically, it's saying do what you would normally do to escape any off-limits XML characters. Technically, greater-than signs don't need to be escaped as long as you escape any less-thans, but most of us do it anyway, just to be safe. Probably the easiest thing to do is just wrap strings in ![CDATA[]], although there may be an oddball deserializer out there that will barf. If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm and enter any of your serialized chunks into the form. It will wrap whatever you input in a method/param, deserialize it, and CFDUMP the results. I don't claim that my (de)serializer is any kind of benchmark, but it'll at least let you know if you're heading down the right path. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215879 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 12:56 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) But although the system does seem to be well supported it also seems to be poorly documented. ;^) Jim: That's a matter of perspective. Some people love Dave Winer's approach to spec-writing, and some people absolutely *loathe* it. I'm gonna guess you're in the latter group. :D I don't feel that strongly about it either way. ;^) It just seems like some pretty big things are missing from the documentation which could easily result in incompatible parsers... I went ahead and set up a little debugger for you. Just go here: http://agincourtmedia.com/xmlrpc/testxmlrpc.cfm and enter any of your serialized chunks into the form. It will wrap whatever you input in a method/param, deserialize it, and CFDUMP the results. I don't claim that my (de)serializer is any kind of benchmark, but it'll at least let you know if you're heading down the right path. Very Cool - thanks! With some quick passes the serializer seems to work with it. I've just finished the JS deserializer (well - at least the first draft - it's not tested yet). Feel like throwing me some test packets? ;^) It's not fully tested but I've now got a single JavaScript object that will serialize and deserialize from JSON, WDDX, XMLRPC (data only) and my own YODEL format. I'm sure it's buggy as hell... but everything works with simple stuff so far. I'm too beat right now but I'll post it for download tomorrow. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215881 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was one of the big points made when Jeremy Allaire and I were discussing his idea of embedding raw data in RSS feeds a couple years ago... not only is it more lightweight than WDDX or SOAP, there's virtually no language or environment that doesn't already support it. That kind of ubiquity is hard to ignore. -- Roger Benningfield JournURL http://admin.support.journurl.com/ http://admin.mxblogspace.journurl.com/ ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215757 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 10:04 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? Mostly because I'd never heard of it until you mentioned it. Where have you been for the past two weeks while I've been ranting about not having something like this. ;^) XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was It does look good - it's just odd that in my posting/searching I never came across it. While I've a bit too much invested in YODEL right now to stop I think I'll still add XML-RPC support (at least for the data format if not for the method calls) to my serialization libraries. Thanks! (Although I still wish you had spoken up two weeks ago. ;^) ) Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215798 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Roger B. [mailto:[EMAIL PROTECTED] Sent: Friday, August 19, 2005 10:04 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) Jim: Any reason not to go with the prior art and just use (or extend, if necessary) XML-RPC? XML-RPC parsers are everywhere, so it's pretty much the no-brainer default option for passing around programmatic data. In fact, that was one of the big points made when Jeremy Allaire and I were discussing his idea of embedding raw data in RSS feeds a couple years ago... not only is it more lightweight than WDDX or SOAP, there's virtually no language or environment that doesn't already support it. That kind of ubiquity is hard to ignore. Okay - I've added XML-RPC data support to my JS serializer extensions. But although the system does seem to be well supported it also seems to be poorly documented. ;^) Right now I'm only creating object-to-string serializers so my solution doesn't actually implement the full method call - it just creates a single the data tag from any JS object. Some questions, if you have the time: +) The system doesn't support explicit nulls (which is fine) but how should a serializer react to them? I can see at least a few ways for handing this: - Convert a null into an empty value: value/value. - Convert a null into an empty string: string/string. - Throw an error. I've assumed the first solution (which I think should work across implementations) but it seems odd that this is left the impelementation. +) The date format for an implementation is sketchy. I've made the assumption that dates will be serialized into UTC dates (with the specified trailing Z) but I see than other implementations either use local time or don't use the trailing Z to indicate UTC. Any idea about what's right? +) String formatting seems... odd. The spec claims that only ampersands and less-than signs should be escaped - is this right? Not even greater-than signs? Nothing for control characters? That's about it... Anyway I've added the serializer to the JS stuff I've been doing and provided examples and source code here: http://www.depressedpress.com/DepressedPress/Test/ If you have some time I'd much appreciate you going over my XMLRPC implementation to see if it measures up. Jim Davis ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215843 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
WDDX Replacement Attempt (was RE: Ajax and CFCs)
[Sorry - I posted this in CFCommunity already but all the action seems to be over here...] I've worked on it some more and have something that, on paper, seems good to me. I've built a JavaScript Serializer (but haven't yet begun to tackle the deserializer). I've created and validated the XSD as well. The basic idea, again, is a solution which can transfer structured data between JavaScript (or, really, any client - but primarily client-side JavaScript) and a server. By structured data I mean things like arrays and objects (structs) nested however deeply you want. My (simplified) goals (and complaints against other solutions) were: +) Something that's easy to parse for JavaScript. SOAP is NOT easy to parse (which is, I think, why there's no generalized SOAP parser for JS). +) Something that maintains general data types. SOAP maintains complex datatypes (based on Java or C+). JSON doesn't offer data typing at all. I thought we needed a middle ground. +) Something in XML. Nearly all modern languages deal with XML natively. The DOM makes dealing with it in JavaScript easy (if tedious). It seemed the way to go. +) Something which could be described using modern XML tools. WDDX, for example, can't be described using an XSD... which may be stupid on the W3C's part but is true nonetheless. But XML/XSD provides a basic level of validation that would have to be built from scratch otherwise. +) Something that's appropriate for both download AND upload traffic. +Often the acts of serializing or deserializing things is left to the server which outputs raw JavaScript code. Or JavaScript is left to receive structured data but is left with only flat form fields to respond. +) Finally, and not the most important, I wanted something that would be relatively small. JSON is VERY small (adding only 5-10% to most data packets) while SOAP or WDDX were VERY big (something quintupling the size of data packets). Again, I thought there should be a middle ground without losing capability. I wanted something to take a complex JavaScript object and pass it, intact, to a server which could take the resulting object, modify it and pass it back, intact. I wanted something JavaScript could both serialize and deserialize relatively quickly and easily. Most importantly I wanted something that _I_ could build and understand in JavaScript and that wouldn't take me a month to do! Lastly I wanted something so simple that it would be easy to recreate in other languages as well. And yet powerful enough not to leave (most) people accepting compromises in their data. So, I've come up with this. I call it dataML (have you got something better?): Three tags only (I decided to minimize them to abbreviations since I'm only using two tags): dataML: This is the wrapper tag for the packet. It can contain, first, any number or zero md tags and one d tag. d: Data. This tag contains the data items. It can contain as many other d tags as you like in an orgasmic orgy of nesting. (By having only one tag we eliminate problems that XSD has with randomly appearing child tags.) It take three attributes: type: The type of the data. I settled on using JavaScript's generalized types (plus the addition of binary). If not provided the data type will default to string. Possible values are: +) object (equivalent to a CF Struct) +) array (single dimensional with sparse arrays supported) +) null +) undefined (I'm not sure if this is actually needed yet) +) string +) number +) boolean (true or false are the only acceptable values.) +) date +) binary (BASE64 Data) +) function (representing a JavaScript function. fields: For objects this is a comma-delimited list of the properties of the object (or, for CF, the keys of a struct). For arrays, if used at all, it would be the indexes filled in a sparse array. It's ignored for all other data types. label: A label which corresponds to a label using in a md (metadata) tag. If used the other attributes will be pulled from the metadata. md: MetaData. This allows us to create a set of attributes to be applied later to multiple data items. While its use may slow down serialization/deserialization using it well can shrink the size of the resulting packet tremendously. We can use md to pre-populate attribute values for d tags. It takes one attribute: label: A label which identifies the metadata. This will be used in the label attribute of d tags. md tags must appear BEFORE d tags. But examples probably say it better. A simple, two property object could be displayed like this: dataML d type=object fields=fname, mname, lname, d type=stringJim/d d type=null / d type=stringDavis/d /d /dataML Where a simple record set could look like this: dataML d type=array d
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215551 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Interesting ideas and it seems like a good direction. The use of the word object seems to trip me up (since I always think of objects as having both values ( properties ) and funcionality ( methods )...) Going to be tough on a name, most of the 4/5 letter ...ml options have been used at this point... - Calvin -Original Message- From: Jim Davis [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 2:09 AM To: CF-Talk Subject: WDDX Replacement Attempt (was RE: Ajax and CFCs) [Sorry - I posted this in CFCommunity already but all the action seems to be over here...] I've worked on it some more and have something that, on paper, seems good to me. I've built a JavaScript Serializer (but haven't yet begun to tackle the deserializer). I've created and validated the XSD as well. The basic idea, again, is a solution which can transfer structured data between JavaScript (or, really, any client - but primarily client-side JavaScript) and a server. By structured data I mean things like arrays and objects (structs) nested however deeply you want. My (simplified) goals (and complaints against other solutions) were: +) Something that's easy to parse for JavaScript. SOAP is NOT easy to parse (which is, I think, why there's no generalized SOAP parser for JS). +) Something that maintains general data types. SOAP maintains complex datatypes (based on Java or C+). JSON doesn't offer data typing at all. I thought we needed a middle ground. +) Something in XML. Nearly all modern languages deal with XML natively. The DOM makes dealing with it in JavaScript easy (if tedious). It seemed the way to go. +) Something which could be described using modern XML tools. WDDX, for example, can't be described using an XSD... which may be stupid on the W3C's part but is true nonetheless. But XML/XSD provides a basic level of validation that would have to be built from scratch otherwise. +) Something that's appropriate for both download AND upload traffic. +Often the acts of serializing or deserializing things is left to the server which outputs raw JavaScript code. Or JavaScript is left to receive structured data but is left with only flat form fields to respond. +) Finally, and not the most important, I wanted something that would be relatively small. JSON is VERY small (adding only 5-10% to most data packets) while SOAP or WDDX were VERY big (something quintupling the size of data packets). Again, I thought there should be a middle ground without losing capability. I wanted something to take a complex JavaScript object and pass it, intact, to a server which could take the resulting object, modify it and pass it back, intact. I wanted something JavaScript could both serialize and deserialize relatively quickly and easily. Most importantly I wanted something that _I_ could build and understand in JavaScript and that wouldn't take me a month to do! Lastly I wanted something so simple that it would be easy to recreate in other languages as well. And yet powerful enough not to leave (most) people accepting compromises in their data. So, I've come up with this. I call it dataML (have you got something better?): Three tags only (I decided to minimize them to abbreviations since I'm only using two tags): dataML: This is the wrapper tag for the packet. It can contain, first, any number or zero md tags and one d tag. d: Data. This tag contains the data items. It can contain as many other d tags as you like in an orgasmic orgy of nesting. (By having only one tag we eliminate problems that XSD has with randomly appearing child tags.) It take three attributes: type: The type of the data. I settled on using JavaScript's generalized types (plus the addition of binary). If not provided the data type will default to string. Possible values are: +) object (equivalent to a CF Struct) +) array (single dimensional with sparse arrays supported) +) null +) undefined (I'm not sure if this is actually needed yet) +) string +) number +) boolean (true or false are the only acceptable values.) +) date +) binary (BASE64 Data) +) function (representing a JavaScript function. fields: For objects this is a comma-delimited list of the properties of the object (or, for CF, the keys of a struct). For arrays, if used at all, it would be the indexes filled in a sparse array. It's ignored for all other data types. label: A label which corresponds to a label using in a md (metadata) tag. If used the other attributes will be pulled from the metadata. md: MetaData. This allows us to create a set of attributes to be applied later to multiple data items. While its use may slow down serialization/deserialization using it well can shrink the size of the resulting packet tremendously. We can use md to pre-populate attribute values
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why not dpxl, seeing as it's not a markup language so much as a data
transfer language that happens to an XML application?
Jim Davis wrote:
+) Something that's easy to parse for JavaScript. SOAP is NOT easy to
parse (which is, I think, why there's no generalized SOAP parser for JS).
+) Something that maintains general data types. SOAP maintains complex
datatypes (based on Java or C+). JSON doesn't offer data typing at all. I
thought we needed a middle ground.
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
typing doesn't imply weak typing, nor does a paucity of type annotation
imply dynamic typing. For the former, see Python, which has strong
dynamic typing, and for the latter, see Haskell and ML, which both have
strong static typing through use of type inference[1].
If you're willing to extend things a little bit by including the syntax
new X(comma seperated list of elements), you can represent dates and
binary data too. I don't see any need for undefined, which can be
denoted by simple absence of data, or function, which ties things to
JavaScript even more tightly, in which case you'd might as will go the
JSON route anyway.
That said, I'm not arguing in favour of JSON so much as pointing out
that by perceived typelessness on its part is not quite the case.
I'd include some kind of explicit recordset type too.
Three tags only (I decided to minimize them to abbreviations since I'm only
using two tags):
dataML: This is the wrapper tag for the packet. It can contain, first,
any number or zero md tags and one d tag.
d: Data. This tag contains the data items. It can contain as many
other d tags as you like in an orgasmic orgy of nesting. (By having only
one tag we eliminate problems that XSD has with randomly appearing child
tags.)
It take three attributes:
type: The type of the data. I settled on using JavaScript's
generalized types (plus the addition of binary). If not provided the data
type will default to string. Possible values are:
+) object (equivalent to a CF Struct)
+) array (single dimensional with sparse arrays supported)
+) null
+) undefined (I'm not sure if this is actually needed yet)
+) string
+) number
+) boolean (true or false are the only acceptable
values.)
+) date
+) binary (BASE64 Data)
+) function (representing a JavaScript function.
I'd say it would actually be less bulky if you changed the names of the
types into tags.
d type=null/
null/
d type=booleantrue/d
booleantrue/boolean
dataML
d type=object fields=fname, mname, lname,
d type=stringJim/d
d type=null /
d type=stringDavis/d
/d
/dataML
dpxl
object fields=fname,mname,lname
stringJim/string
null/
stringDavis/string
/object
/dpxl
{fname: Jim, mname: null, lname: Davis}
Where a simple record set could look like this:
dataML
d type=array
d type=object fields=text, value,
d type=stringFund One/d
d type=stringFund01/d
/d
d type=object fields=text, value,
d type=stringFund Two/d
d type=stringFund02/d
/d
d type=object fields=text, value,
d type=stringFund Three/d
d type=stringFund03/d
/d
/d
/dataML
dpxl
array
object fields=text,value
stringFund One/string
stringFund01/string
/object
object fields=text,value
stringFund Two/string
stringFund02/string
/object
object fields=text,value
stringFund Three/string
stringFund03/string
/object
/array
/dpxl
[
{text: Fund One, value: Fund01},
{text: Fund Two, value: Fund02},
{text: Fund Three, value: Fund03}
]
But over large numbers of records the repetition of the metadata would
inflate the packet terribly. So we use the md tag like so:
dataML
md label=option
d type=object fields=text, value,
d type=string /
d type=string /
/d
/md
d type=array
d label=option
dFund One/d
dFund01/d
/d
d label=option
dFund Two/d
dFund02/d
/d
d label=option
dFund Three/d
dFund03/d
/d
/d
/dataML
This shrinks the serialized version of the data tremendously when you want
to return large numbers of similar objects (as with a record set).
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
dataML
type name=option
d type=object fields=text,value
d type=string /
d type=string /
/d
/type
d
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
At 02:33 AM 8/18/2005, you wrote: Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) How about DEML [dimmel] for data expression or exchange ML? -- Phillip Beazley Onvix -- Website Hosting, Development E-commerce Visit http://www.onvix.com/ or call 727-578-9600. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215569 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis XML Data Language (XDL) XML Data Format (XDF) XML Information Language (XIL) XML Information Format (XIF) s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215614 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
XIEF (XML Information Exchange Format) -Original Message- From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 10:33 AM To: CF-Talk Subject: RE: WDDX Replacement Attempt (was RE: Ajax and CFCs) Well - it looks like dataML is already taken for something else anyway... anybody got a good idea for a new name? I'm thinking either simple as in dpml (Depressed Press Markup Language) which says absolutely NOTHING about what it does or esoteric like Rosetta. Whatcha think? I know this is weighing heavily on all your minds! ;^) Jim Davis XML Data Language (XDL) XML Data Format (XDF) XML Information Language (XIL) XML Information Format (XIF) s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215628 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Keith Gaughan [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 7:57 AM To: CF-Talk Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why not dpxl, seeing as it's not a markup language so much as a data transfer language that happens to an XML application? Perhaps... I do like to add dp to things. ;^) Not quite true. The data typing in JSON is implicit. Of the types listed below it can unambiguously represent object, array, null, string, string, boolean, and number. It's all implicit in the syntax. Dynamic That's true I guess. But there IS more: JSON also can't represent non-numeric keyed arrays (something called JavaScript Hashtables) for example. I had considered extending the JSON syntax but decided against it on principle: the beauty and simplicity of any JSON packet is that it IS JavaScript code. Any extensions would break that elegance... so I didn't want to touch it. (As an aside - I really like JSON a lot... the JS library I'm bulding for this stuff will also do JSON... I actually envision an application that's smart enough to know which transport mechanism is required based on the complexity being transferred...) I'd include some kind of explicit recordset type too. I consider that for a long... long time... but decided against it. Any representation of a recordset I've ever seen is either column-based (which is an object whose properties are arrays) or record-based (which is an array of objects). Both of these representations can be done using Arrays and Objects so why is it really needed? Either we create a custom RecordSet object in JS or we convert it to the native data types... but since the latter is just as easy as the first for JS why bother? I'd say it would actually be less bulky if you changed the names of the types into tags. d type=null/ null/ d type=booleantrue/d booleantrue/boolean The main problem here is that it's impossible to describe such a language an XSD (unless you allow any tag - which includes xHTML, made up tags, etc - in any place). XSD only allows a tag to contain ordered tags or any tags (so the former would force us to say that object must appear before array which must appear before string and so forth - which makes the serialization an order of magnitude more complex). This shrinks the serialized version of the data tremendously when you want to return large numbers of similar objects (as with a record set). I'd like to point out that here the md tag is essentially defining a new type, so you could change this to: I could... but in keeping with the theme, if I did do it would probably be a dt (data type) tag. ;^) But I may do this... although I'm comfortable with both concepts if one makes easier for others then, great. dataML type name=option d type=object fields=text,value d type=string / d type=string / /d /type d type=array d type=option dFund One/d dFund01/d /d d type=option dFund Two/d dFund02/d /d d type=option dFund Three/d dFund02/d /d /d /dataML But there are questions. Should default data be allowed in meta data (if you fill in the content of the tags should that content be used if no content is provided in the d tags)? I'd say so, yes. Yeah... I'm leaning that way as well... but I'm also fearing building the deserializer. ;^) Should metadata for the contents of an array automatically apply to ALL children of that array? In other words should this be legal: Definitely. As I said, md is essentially a type declaration, so yes. Mind you, such a generalisation would complicate the serialisers and deserialisers a bit. Yeah... that's a fear. Mostly the Deserializers I think: I still think that, in practice, the whole idea of metadata/custom types will be used only in certain situations an problems require custom code anyway. Since all they do is cut down on verbosity I'm debating on even keeping them... but I do really like the concept. Should such a thing force all children of the array to be the same? Yes, unless you want to reserve the undefined type for use in md to represent somewhere where the types are specified in the body. I was thinking more organically on this one. My thinking would be that the type would only apply as a mask to the linked elements. So, if a child tags type was defined it would apply it, if not it wouldn't. If it defined an object but no properties then that object could have any properties. This is one reason that I'm NOT super comfortable with the type concept... it seems to imply a full definition when it could only part of one. In most cases you won't need the md at all. It's ONLY needed to save space. All deserializers should
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message- From: Calvin Ward [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 7:32 AM To: CF-Talk Subject: RE: WDDX Replacement Attempt (was RE: Ajax and CFCs) Interesting ideas and it seems like a good direction. The use of the word object seems to trip me up (since I always think of objects as having both values ( properties ) and funcionality ( methods )...) The basis for (almost all of this) is JavaSript - that's where object comes from. Although note that there is a function type - so, in theory, you can pass objects (at least JavaScript objects) with methods and properties via the dialect. I say in theory because I've no idea about in practice this would work however... ;^) Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215647 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Davis wrote:
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
That's true I guess. But there IS more: JSON also can't represent
non-numeric keyed arrays (something called JavaScript Hashtables) for
example.
Ah, but isn't that what an object in JS(ON) essentially is?
{
I am: a string-keyed,
array or: a hashtable,
if: you will.
}
I'd include some kind of explicit recordset type too.
I consider that for a long... long time... but decided against it. Any
representation of a recordset I've ever seen is either column-based (which
is an object whose properties are arrays) or record-based (which is an array
of objects).
Both of these representations can be done using Arrays and Objects so why is
it really needed? Either we create a custom RecordSet object in JS or we
convert it to the native data types... but since the latter is just as easy
as the first for JS why bother?
True, but I was thinking that it might be nice to annote it as such.
The main problem here is that it's impossible to describe such a language an
XSD (unless you allow any tag - which includes xHTML, made up tags, etc -
in any place). XSD only allows a tag to contain ordered tags or any tags
(so the former would force us to say that object must appear before
array which must appear before string and so forth - which makes the
serialization an order of magnitude more complex).
Hmmm... I heard XSD was a bit odd, but I didn't think it was *that* bad.
Holy crap! I think I'll stick with DTDs then.
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
I could... but in keeping with the theme, if I did do it would probably be a
dt (data type) tag. ;^)
Fairy nuff. :-)
Should such a thing force all children of the array to be the same?
Yes, unless you want to reserve the undefined type for use in md to
represent somewhere where the types are specified in the body.
I was thinking more organically on this one.
My thinking would be that the type would only apply as a mask to the
linked elements. So, if a child tags type was defined it would apply it, if
not it wouldn't. If it defined an object but no properties then that
object could have any properties.
You could do that alright. I was just thinking of a situation where you
might have something like this:
dt name=wotsit
d type=array
d type=object fields=id,name,value
d type=number/
d type=string/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
/d
/dt
/dt
Where the value might be an object or an array of objects.
This is one reason that I'm NOT super comfortable with the type concept...
it seems to imply a full definition when it could only part of one.
Nah, types can be just partial definitions of what's going on too.
K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDBLk0mSWF0pzlQ04RArLqAKDAsLs7RDuzsykZFgVRVoQ+5rjzegCfTESs
dHAnWesEpA5/BmCam4IiXKI=
=rFSC
-END PGP SIGNATURE-
~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:215650
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 18, 2005 12:37 PM
To: CF-Talk
Subject: Re: WDDX Replacement Attempt (was RE: Ajax and CFCs)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Davis wrote:
-Original Message-
From: Keith Gaughan [mailto:[EMAIL PROTECTED]
Not quite true. The data typing in JSON is implicit. Of the types listed
below it can unambiguously represent object, array, null, string,
string, boolean, and number. It's all implicit in the syntax. Dynamic
That's true I guess. But there IS more: JSON also can't represent
non-numeric keyed arrays (something called JavaScript Hashtables) for
example.
Ah, but isn't that what an object in JS(ON) essentially is?
{
I am: a string-keyed,
array or: a hashtable,
if: you will.
}
Not really. Sorta/kinda.
JavaScript IS WEIRD - just so we have that straight before we start.
There's definitely a method to its madness, but it IS weird. ;^)
You can do this:
myOb = new Object();
myOb.myProp = value;
AND
myAr = new Array();
myAr[myProp] = value;
However, as alike as they look, doing a typeof for both will still return
object and array.
This is a subtlety to be sure - but one which JSON can't distinguish
between. That last array can't really be done as an array in JSON (the
commonly available JSON parser actually just ignores the values completely).
This is strange, but understandable. In the second case you're adding
properties to an (array) object - perfectly legal. But it is strange (it's
also pretty common in use).
The main problem here is that it's impossible to describe such a
language an
XSD (unless you allow any tag - which includes xHTML, made up tags,
etc -
in any place). XSD only allows a tag to contain ordered tags or any
tags
(so the former would force us to say that object must appear before
array which must appear before string and so forth - which makes the
serialization an order of magnitude more complex).
Hmmm... I heard XSD was a bit odd, but I didn't think it was *that* bad.
Holy crap! I think I'll stick with DTDs then.
Yeah... I probably should have. For me I'm damned if I do, damned if I
don't with XD.
XSD also can't validate based on attribute values - which means it can't
validate much of this at all.
But still... it does work.
I'd like to point out that here the md tag is essentially defining a
new type, so you could change this to:
I could... but in keeping with the theme, if I did do it would probably
be a
dt (data type) tag. ;^)
Fairy nuff. :-)
I was thinking about this more...
The only real problem I see is that I would have to make the type
attribute accept any value (in the XSD at least) - there could be no
validation on type.
I'm not sure how I feel about that... I guess needing to make it optional to
support the md as it was is just as bad, uh?
I'm (like in so many things) back and forth on it.
My thinking would be that the type would only apply as a mask to the
linked elements. So, if a child tags type was defined it would apply
it, if
not it wouldn't. If it defined an object but no properties then that
object could have any properties.
You could do that alright. I was just thinking of a situation where you
might have something like this:
dt name=wotsit
d type=array
d type=object fields=id,name,value
d type=number/
d type=string/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
/d
/dt
/dt
Where the value might be an object or an array of objects.
I would think either we use just plain d / or put nothing at all.
The latter would indicate that although a value could be there - we've got
no attributes to apply to it. User's choice.
A clearer example might do this:
dt name=wotsit
d type=array
d type=object fields=id,value,name
d type=number/
!-- The next element could have any type: do we use... --
d/
!-- Or... --
d type=undefined/
d type=string/
/d
/dt
/dt
In this case we really need a place holder of some kind to ensure that the
string type will be applied to correct field.
But I still thing an empty d / is best here - since the underlying idea of
this is that attributes of the new type will replace the corresponding
attributes of the linked thing showing this with no attributes will cause no
substitutions.
A key of this is that the custom types aren't enforcing strict adherence (or
at least I don't think they should). Any attributes not defined are left to
the user to fill in as they like.
Sound good?
This is one reason that I'm NOT super comfortable with the type
concept...
it seems to imply a full definition when it could only part of one.
Nah, types can be just
