IDE Minutes 2009 06-30

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_06-30

Contents

Attendees

  • Lori Hylan-Cho
  • Javier Pedemonte, IBM
  • Jon Ferraiolo, IBM


Minutes

Agenda email:


(11) Outstanding editorial tasks

  • Factory method example
  • CDATA discussion within widget chapter
  • Example for <parameter> section
  • Example for 'includeRef'

(Discussed first, at very start of meeting)

Lori: I'm working on a Google Gears example for the factory method section

Jon: Very good


(1) ISO/UTC Dates 

We seem to have converged on normatively referencing RFC3339, but
tell people to use only uppercase T and Z (to be upwardly compatible
with upcoming ECMA5)

We have been talking about 'defaultValue', but doesn't same issue apply to
'minimum' and 'maximum' constraint attributes (which also apply to dates)?

Jon: I've had emails with Adam about this. Adam is one of IBM's localization experts.

RESOLUTION Agree to reference RFC3339, but say that T and Z must be uppercase. Also applies to 'minimum' and 'maximum'.


(2) Add @format=date,time,timestamp 

Scott says "I think there are applications where you will want to
specify a date without a time"
Jon says yes, but two separate issues.
For how to express defaultValue for datatype="Date", see topic (1) above.?
For property editor requirements, I propose adding
@format=date,time,timestamp

Jon: My recommendation from last week was to leave these out because we have "Date", but quickly realized that tools needs to know whether it's a date or time so they can post a calendar widget or some sort of clock widget. Scott points this out, also.

Javier: If @format=date, what is @datatype?

Jon: Adam and I concluded it should be Date.

Javier: How to implement? Implementation-specific?

Jon: Whenever needing to interchange, you send a JS Date type. If @format=date, on usage, strip out the time part, including timezone. If @format=time, strip out the data part, leaving time and timezone.

RESOLUTION: Add @format=date|time|timestamp. Applicable to @datatype=Date.


(3) Add @format to <topic> element 

We have @format on <property> but not <topic>.
Mashup frameworks sometimes can leverage
the supplemental information for linking topic publishers with topic,
subscribers. Without 'format', the mashup framework pretty much can only
link publishers and subscribers based on topic name. With 'format', there
will be some ability to match publishers and subscribers based on the type
of payload.

Javier: Makes sense to me.

RESOLUTION: Add @format to <topic> element


(4) Minor changes/cleanups with <require> and <library> 

Added 'includeRef' to <library>
Made 'src' optional on <require>

Lori: Is there a real-world case for includeRef="false" on <library>?

Jon: No, just hypothetical. Assume scriptaculous includes prototype automatically, which it doesn't do in real life. But if it did, then you might put includeRef="false" on the <library> element for prototype.

Lori: I would say that "although no real-world examples come to mind, this allows for possibility"

Jon: Makes sense to me.

RESOLUTION: Schema changes as proposed, but add text about how no real-world examples come to mind


(5) Add @src to <reference> 

To allow for referencing a Web page

Lori: Don't we have URIs all over the place on the widget side?

Jon: Yes, but nothing in descriptive metadata.

Lori: We have an aboutUri attribute on widget.

Jon: Oh, yeah, we do. That's the most critical thing. For other uses, people can type a Uri string into the text content of <reference> or other things. So, drop this enhancement?

Lori: Sounds logical.

RESOLUTION: Don't add @src to <reference>


(6) Various minor issues in Datatypes chapter 

(a) @datatype referencing a JS class name - not allowed for widgets? Jon
says not allowed
(b) @datatype not recognized: use "Object" or "*"? Jon suggests "*"?
(c) @format: Instead of MUST ignore constraint attributes, Jon suggests MAY
ignore
(d) @minimum/@maximum for strings: long-term open issues. Jon says no
(e) 'pattern' attribute: require slashes around regex value? Jon says no

(a) @datatype referencing a JS class name

Jon: Widgets don't have <class> element

Javier: But what if a widget is referencing one of its own classes?

Lori: Any harm in allows reference to a JS class name?

Javier: I don't see why we wouldn't allow it. Maybe the constructor needs to take a particular string?

Jon: I don't like the string idea. I'll note that there is a fallback. If a tool doesn't understand a datatype, it falls back to Object.

Javier: Constructor needs to parse the defaultvalue string. Best to call that out.

Jon: OK

Lori: One of the widgets on the Dreamweaver exchange allows String or Object. Would you say String or Object? Allow a class?

Javier: Better to say foo.bar.x than just Object.

Lori: Mostly serves as info for tool about the datatype

Javier: I say keep it unless we find a scenario where it causes problems

Lori: I agree

RESOLUTION: Leave spec as is - widget @datatype can refer to a class

(b) @datatype not recognized: use "Object" or "*"? Jon suggests "*"?

Lori/Javier: Sounds fine

(c) @format: Instead of MUST ignore constraint attributes, Jon suggests MAY ignore

Jon: Why tell a tool it can't use metadata that is provided?

Lori: Totally agree

RESOLUTION: Change MUST to MAY regarding @format and constraint attributes

(d) @minimum/@maximum for strings: long-term open issues. Jon says no

Jon: Open issue for about a year. Whether to say minimum string is "aaa" and maximum string value is 'zzz', or things like that. Can do that via 'pattern' attribute and regexp.

Lori/Javier: Agree

RESOLUTION: 'minimum' and 'maximum' don't apply to strings

(e) 'pattern' attribute: require slashes around regex value? Jon says no

Javier: Define our the value as anything that a RegExp constructor will accept, which means no slashes

Lori/Jon: OK

RESOLUTION: As Javier says


(7) CDATA for type="text/plain" when HTML characters are used 

Jon proposes that we instruct metadata developers to bracket text that
includes HTML special characters with CDATA.

Jon: We say that descriptive text which is rich HTML text should be bracketed with CDATA if it contains any problematic characters to an XML processor, but for plain text we say to use entities. Seems wrong to me. Why tell people to mess with entities. Instead, use CDATA for plain text, just like what we say for rich text.

Lori/Javier: Yes

RESOLUTION: Plain text descriptions that use characters important to XML should use CDATA


(8) Proposed loose wording for algorithm for finding localization files 

Spec just says RFC 4647 has algorithms. Doesn't say you must any particular
algorithms.
Jon thinks this is the right way to go.

Jon: RFC 4647 provides 3 major algorithms. I don't think we can require one particular algorithm, and probably shouldn't. So spec says now that here is a spec that provides algorithm, and nothing else. I think that's OK, but wanted feedback.

Lori: I don't know enough to comment

Jon: Let's leave this for next week


END OF MEETING

Retrieved from "http://www.openajax.org/member/wiki/IDE_Minutes_2009_06-30"
Personal tools