-----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
