You see me relieved ☺ Thanks for the precision.
Still, using “String” style for types in jsType as opposed to “string” will allow for arbitrary types.
From: Jon Ferraiolo [mailto:jferrai at us.ibm.com]
Sent: Friday, November 16, 2007 11:37 AM
To: Bertrand Le Roy
Cc: ide at openajax.org
Subject: RE: [OpenAjaxIDE] Dojo date picker in XML
Oh, maybe you don't understand how the JSON and XML relate to each other. It is *not* meant to be two different encodings of the same infoset.
The JSON representation was the original jMaki widget as it shipped with the jMaki 1.0 distribution. The XML representation is the same *general* information expressed in our proposed XML grammar.
The only reason for inclusion the JSON is to show how jMaki expressed the information, but that's just background reference information. My assumption is that there is only one expression for our metadata and it is in XML.
Jon
[cid:image001.gif at 01C82847.008C4180]Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
11/16/2007 11:11 AM
To
Jon Ferraiolo/Menlo Park/IBM at IBMUS
cc
"ide at openajax.org" <ide at openajax.org>
Subject
RE: [OpenAjaxIDE] Dojo date picker in XML
Well, consistency between the JSON schema and the XML schema would be preferable in my opinion. It should be trivial to go from one to the other even without knowledge of the grammar.
I don’t think we should take JSON as the reference on how types are specified: it really is unspecified in JSON as the type is inferred from the literal syntax. Plus, JSON is based on the idea that it’s only data and only uses that handful of built-in types (by the way, Date is severely missing but that’s a different topic). In our case, the scenario is fundamentally different as we’re describing APIs where complex types are perfectly OK.
Bertrand
From: Jon Ferraiolo [mailto:jferrai at us.ibm.com]
Sent: Friday, November 16, 2007 10:16 AM
To: Bertrand Le Roy
Cc: ide at openajax.org
Subject: RE: [OpenAjaxIDE] Dojo date picker in XML
Hi Bertrand,
The complete explanation of why the XML and JSON do not match is that during the moments when I wrote up the strawman proposal I somehow felt it was desirable for the XML to have a different expression. I didn't think about any topics deeply. I don't particularly care about what elements or attributes are named. But I did give things some thought and attempted to take into account reconciliation with other overlapping efforts, such as how other vendors expressed their JavaScript APIs (e.g., Aptana calls them properties whereas jMaki calls them args), what I saw in the Gadgets TF proposal, and what I saw in the W3C Widgets proposal. Also, while jMaki is largely aligned with what the various activities require at OpenAjax, I felt that there were some things in jMaki that were either not appropriate or at least not in good alignment. Bottom line: I was arbitrary.
Basically, I just wanted to take my best shot at a reasonable starting point that would allow OpenAjax to define a consolidated widget grammar that could work reasonably across multiple workflows (IDE, Gadgets, W3C Widgets).
However, I also assume that every single XML element and attribute would be reviewed, many (perhaps most) would be changed, and that people would change large parts of the XML grammars after group discussion.
Regarding why jMaki used STRING vs string vs String, we'll have to hear from the JSON folks. My vote is that we should use the same capitalization approach as the JavaScript spec when talking about JavaScript types. I think that would result in "string".
Regarding types, my personal favorite approach is to offer two type values for each property, a JavaScript type and an XSD type (XML Schema Datatypes). The JavaScript type is (obviously) what is important when addressing JavaScript-centric requirements. For high-level datatyping, such as "non-negative integer" or enumerations, I am a fan of leveraging existing standards. XSD is a bit heavyweight, but I don't think it's heavyness would drag down many users. In the 90/10 scenarios, 90% of the time people would use the primitive data types in XSD, which can be expressed as a single string, but there is a robust growth path for more complex data types.
Jon
[cid:image001.gif at 01C82847.008C4180]Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
11/16/2007 09:18 AM
To
Jon Ferraiolo/Menlo Park/IBM at IBMUS, "ide at openajax.org" <ide at openajax.org>
cc
Subject
RE: [OpenAjaxIDE] Dojo date picker in XML
Why is there a difference in names between the xml and json? TopicInfo seems to be the same as pubsub but all the names are different.
Why are some type names in JSON capitalized? For a string, I'd say either "string"or "String" can work depending on how you test the type (typeof or instanceof) but "STRING" doesn't work. I'd prefer if we used "String"/instanceof because that opens up the possibility of specifying complex types better than just "object".
About types, could we keep the type attribute reserved for actual JavaScript types (I don't think "publish" is a type)? The type in config (JSON) is a little confusing too (and I think there's a missing brace).
Thanks,
Bertrand
________________________________
From: ide-bounces at openajax.org [ide-bounces at openajax.org] On Behalf Of Jon Ferraiolo [jferrai at us.ibm.com]
Sent: Friday, November 16, 2007 8:52 AM
To: ide at openajax.org
Subject: [OpenAjaxIDE] Dojo date picker in XML
I completed my assignment from yesterday's phone call, which was to express the Dojo date picker widget in our strawman widget XML grammar. Here is the link:
* http://www.openajax.org/member/wiki/IDE_Widget_Sample_Dojo_DatePicker
I also modified the IDE wiki page ("Work in progress" section) to point to the above wiki page and also include links to future wiki pages for the Yahoo menu widget and a Google map widget.
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071116/cad2b81f/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
Url : http://openajax.org/pipermail/ide/attachments/20071116/cad2b81f/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 168 bytes
Desc: image002.png
Url : http://openajax.org/pipermail/ide/attachments/20071116/cad2b81f/attachment-0002.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 166 bytes
Desc: image003.png
Url : http://openajax.org/pipermail/ide/attachments/20071116/cad2b81f/attachment-0003.png