> -----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="boolean">true</d> > <boolean>true</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"> > <d>Fund One</d> > <d>Fund01</d> > </d> > <d type="option"> > <d>Fund Two</d> > <d>Fund02</d> > </d> > <d type="option"> > <d>Fund Three</d> > <d>Fund02</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 understand it, but serializers don't > have > > to implement it. > > Postel's law, in a way. Yeah... I actually see a lot of that in this. There are a lot of "Defaults" and shortcuts designed to let people be lazy with their packet generation. If you leave out a "type" this assumes "string". If you add a "fields" attributes to a data type that doesn't need one it ignores it and so forth. I can see where some people would stand against that kind of thing... but I like it (and, honestly, I think it makes coding the parsers a bit easier in fact). 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:215637 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
