IDE Minutes 2008-02-15

From MemberWiki

Jump to: navigation, search



  • Kris Zyp, SitePen & JSON Schema project
  • Kevin Hakman, Aptana
  • Jon Ferriaiolo, IBM
  • Phil Berkland, IBM
  • Greg Murray, Sun
  • Sandip, Sun


Future meetings will now be weekly, at 1PM Pacific Time

Continuing to walkthrough the wiki page at

Jon: JS APIs and JS UI element share wmae property element. It's big area with lotsof potential attributes -- and overlaps with JSON schema. Jan and Feb have been spent on refining the property elemtn, it's attributes and how we want it to wrok. e've done a comparison table and the JSON schema spec, then over 66% of that table we've made tentative decisions for our spec, realtive to that topic. We've made lots of progress. When we get through this table, we'll have made considerable progress. Left off with the minimum and maximum attributes?

Jon: re: Minimum and Maximum attributes, Rich Thomposon suggested some level of centralized markup associated with contraints to say how the values are constrained. A proposal indead of min and max attribute that we hav a contraints attribute, then a json syntax for min, max and for example "required". Second approach would be subelement <constraint>. But mostly that we find a way to separate out the contraints into their own area of markup.

multiple voices: I like it, yes.

Jon: I'm not a fan of this.

Kevin: I find it architeurally sound, but verbose in practce -- keep it simple

Jon: In the industry in practice like with Aptana is just kep top-level "min", "max"

Phil: in favor of it.

Kris: I'm abiguous. But keeping it top level keeps it simpler.

Jon: in the spec docs's let's group is by documentaiton as "Constraints" but not in the syntax.

Kris: in JSON schema we have minLength, maxLength for strings and minItems and maxItems for arrays.

Jon: Bertrand also mentioned minDate and maxDate

Kevn: can we just infer the type from the context within which maximum and minimum are included.

Kris: Yes, but there's amibguity in the context of an array of numbers.

Jon: I'm fine with what the JSON schema guys are taking. What

Kevin: I like the non-ambiguity too.

Kris: Minmum and maximum meaning comparative value. Whereas minLength means characters and maxItems relates to a count of items. Thus minimum and maximum can be applied to numbers and dates, but also perhaps strongs (needs to be validated).

Jon: Let's go wth the resolution, then we need to determine of strings are included if it's well executed across browsers.

Jon: Let's move on to patterns. Does anyone object?

Kris: RegEx's have dialects. In JSON schema we use Perl5, ECMA262 spec.

Kevin: Let's note that in the spec.

Jon: Next let's drop length since it's taken care of with minLength and maxLength.

Jon: Next is "Options" to handle enumerations.

Kris: in JSON schema it's an array.

Jon: We have a subelement containing addedition subitems, with each having 2 attributes: value and displayvalue. This was based on Google Gadgets syntax (except we use camel case and Goolgle always starts with a cap)

Kris: That's somehting considering changin in JSON schema to label value pairs.

Jon: What do people thing of that approach?

Kris: JSON schema should take on the ability to handle this case. I think it makes sense to use XML to do that.

Jon: Yes, then you can use XSLT script to localize, etc… So I'm in facor of this approach.

Kevin: Anyone object to that approach?

Greg: Do they have a document of URL for the Google Gadgets precedent? I'm fine with the approved, but let's include that refernece URL.

Kevin: What's next on our list?

Jon: Unconstrained?

Kris: This allows the combination of enum values, but also allowance for custom values too.

Kevin: Seems like a good case to include. What should the semantics be? Is "unconstrained" the right semantic?

Kevin: Any objections to theproposal?


Kevin: OK, let's book it as posposed.

Jon: Next readonly. This was the same in both. Suggest let's

Kevin: Anyone object to the pospoal?


Kevin: OK, let's move on.

Jon: In IDE spec there was a longDesc and shortDesc. There was a case where if you were generatig an inspector dialog, you could use a string other than the property name in the display. One reason you might want to do that is localization. But the title is the thing that you would localize.

Kris: JSON schema can include this. I'm editing JSON schema now and addinf title in there. It's an optional.

Kevin: Anyone object?


Jon: Next one is "transient" which exists in JSON schema. This property is used for transient values that should not be persisted.

Kevin: In GI runtime IDs are transient.

Jon: Other cases like in mashups could use this for debugging time, etc… transient is the main thing that tells the tools what to persist or not persist -- transient things do not get persisted. It's there to notify whether to persist or not? Implemeters that do not care about transient can ignore it.

Jon: does JSON schema have "hidden"

Kris: No, but that's a good idea. I'll bring it up.

Jon: let's propose "transient" and "hidden"


Kevin: OK. Adopted as proposed.

Greg: on the "listen" it can be an array?

Jon: "listen" is addative, ontop of the publish and subscribe foundation, for a short-hand way to create a publisher a an inline way to publish. It's a redendant mechanism. For the case of listening to an array of topics, you'd use the pub/sub syntax, not the short hand "listen", but that said we've not gone throughthat item as of yet.

Personal tools