> -----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 partial definitions of what's going on too.
Yeah - at this level it's all semantics anyways. I just tend to get hung up
on labels (I'm a usability person by training). ;^)
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:215663
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
