IDE Minutes 2008 07 01
- Bertrand Le Roy, Microsoft
- Jon Ferraiolo, IBM
- Stew Nickolas, IBM
- Ted Thibodeau, OpenLink
API chapter questions
Jon: Let's start with the email I sent titled "Some questions for Ingo (and everyone else)"
(1) (QUESTION SPECIFICALLY FOR INGO) The ScriptDoc XML page says that a <method> can have an <attributes> child element, but there is no <attributes> element listed in the ScriptDoc XML page. Is this an editorial error?
Jon: Question (1) is for Ingo and Aptana. Let's go to question (2).
RESOLUTION: Need Ingo/Aptana to respond to this one.
Stew: Yes, that's my understanding
RESOLUTION: Yes, 'name' is for *definitions* and 'datatype' is for *referencing*
(3) Same question applies to <interface>, but one more thing on <interface>. Our spec right now has a 'type' attribute. Assuming we use 'name' to give the interface a referenceable name, I assume we don't need 'type' (or 'datatype'). Correct?
RESOLUTION: Yes, there should not be a 'type' attribute on <interface>
(4) For the <alias> element, we only have a 'name' attribute, whereas Aptana ScriptDoc XML has both 'name' and 'type'. My thinking is that our metadata spec should have both 'name' and 'datatype', where 'name' is alias's name/handle and 'datatype' is a reference to thing that is being aliased. Correct?
Stew: I agree with the analysis.
RESOLUTION: Yes, <alias> should have both 'name' and 'datatype'
Jon: Bertrand, you are the person on the call who would understand <alias> the best.
Bertrand: I don't know. I don't think we use it.
RESOLUTION: Need Ingo/Aptana to respond to this one.
(6) Right now, our spec shows a 'visibility' attribute on <constructor>, <interface> and <class> (and presumably <field>, where I recently fixed some editorial errors), where visibility="public|private|protected| internal|protected-internal". Aptana has 'visibility' and <class>, <constructor>, <method> and <property>. It seems like 'visibility' should be on <class>, <constructor>, <method>, <property> and <field>. Does 'visibility' make sense on <interface> and <mixin>?
Bertrand: Yes of the first five. But also include <interface> and <mixin>. Might be used internally in private classes.
RESOLUTION: 'visibility' on <class>, < constructor>, < method>, < property>, < field>, < interface>, < mixin>,
(7) I forgot what <namespace> does. Can someone remind me so I can add text to the spec?
Bertrand: For when a library defines a namespace, such as the OpenAjax namespace
Stew: Example of "MyLibrary.io.xhr". Two namespaces, "MyLibrary" and "MyLibrary.io", enclose the close "xhr".
Bertrand: For object that you don't typically instantiate. Can have other namespaces or classes. May not make sense for certain frameworks such as jQuery, but makes a lot of sense for MS Ajax.
RESOLUTION: OK, thanks.
(Jon now has enough information to do the spec work.)
...Jon gives outline of InteropFest, which covers both IDE workflows and mashup workflows...
Jon: For IDE workflows, first thing is something to verify that an Ajax library has or can generate proper OpenAjax Metadata. I am proposing a library checker widget within the "reference implementation" (i.e., the open source mini mashup editor that Stew and others have developed that supports OpenAjax Metadata and OpenAjax Hub 1.1)
Stew: Maybe good to set up a SaaS with REST API where the backend verifies the library, but the reference implementation contains a small front-end to the REST API. That way the library verification can be done outside of the reference implementation
Jon: Good idea
Jon: One thing to mention is that I don't have a full proposal yet for how to implement the library checker. Library checker needs to do a recursive search through a directory to find files that match a naming pattern. Options include pointing the library checker to a URL and the spider through the web site, or require people to ZIP up their library and upload to our site for verification, or we provide a tool that they can install on their computer in order to run the verifier. I am still thinking things through.
Bertrand: Sounds good.
Jon: Any other comments on the InteropFest?
Bertrand: About the ordering. Maybe put the IDE part at the top?
Jon: Yeah, I have been feeling uncomfortable because Ajax libraries are now listed as the last thing. Anyone object to lifting IDEs and Ajax libraries before the mashup items? I think that works OK because the repository line would be last and that's the most tenuous part of the InteropFest
Stew/Ted: No objections
RESOLUTION: IDEs first
Jon: First question. What if %%whatever%% but there is no "whatever" entry in any of the localization files? I propose that the string %%whatever%% appears to the user.
Ted: Yes, leave the original.
Bertrand: Our system offers more flexibility. We allow a fallback value in the original content. There is a 'locid' attribute on the element. If you don't find a localized string corresponding to the 'locid', use the content of the element as the fallback.
...long discussion about various options, most of which were complicated. Concluded that 'locid' approach wasn't needed within <content>. Use case is for descriptive elements, such as <description>...
...subsequent discussion about 'localizationKey' versus 'locid' as the name of the attribute...
RESOLUTION: Use 'locid' (like Microsoft). Applies to any element that can take text. Jon to submit detailed proposal.
Jon: I proposed the Gadgets format because it is simple and straightforward and Gadgets is used by tens of thousands of developers, although probably few of them have localized their Gadgets yet.
Bertrand: Our format is widely used.
Jon: You agree we would have to use a different namespace from the MS one?
Jon: Why is it necessary to wrap the text in a <value> element? Seems superfluous.
Bertrand: Not needed but that's the way it is
Jon: Would be easy to transcode to/from a simpler format to fix the namespace and add/remove the <value> element
Bertrand: Yes, sure, but wouldn't work directly with our tool. We also have nice features like localization of binary sources.
Jon: I prefer the simpler approach
RESOLUTION: Adopt the Gadgets localization file format
Jon: How about file naming rules, such as en_us.xml and ALL_ALL.xml? Anyone here an expert on the RFCs?
Stew: Google's approach looks straightforward and good, but I'm not an expert about whether it is robust.
Jon: OK, I'll ask Adam Peller, who talks at conferences about localization and did the Dojo work.
RESOLUTION: Jon to bug Adam about file naming approaches for localization