Interoperability Minutes 2008-04-23

From MemberWiki

Jump to: navigation, search

Full minutes: http://www.openajax.org/member/wiki/Interoperability_Minutes_2008-04-23

Contents

[edit]

OpenAjax Alliance Interoperability Committee meeting minutes 2008-04-23

[edit]

Attendees

  • Jon Ferraiolo, IBM
  • Ted Thibodeau, OpenLink SW
  • Bertrand Le Roy, Microsoft
  • Rich Thompson, IBM
  • Javier Pedemonte, IBM
  • Kin Blas, Adobe
  • Gideon Lee, OpenSpot
  • Alex Russell, Dojo
  • Andrew Betts, Assanka
[edit]

Resolutions from this meeting

RESOLUTION: Add a new field to Registry to reflect which nodes a toolkit "owns"

RESOLUTION: The name of that new field will be discussed on email

RESOLUTION: Add words to Registry wiki page to warn about potentially confusing syntax with attributes (i.e., bracket quote bracket quote)

RESOLUTION: Asterisk (*) is allowed in attributes, elements and classnames. (Presumably only at end)

RESOLUTION: Approved Jon's proposed process going forward (see detailed minutes for description)

RESOLUTION: Add text to Registry wiki page telling developers to describe their XML namespace prefixes and namespace URIs within the comments field

[edit]

Original Agenda

[edit]

Minutes

(Jon introduces the meeting, saying the one and only subject is the OpenAjax Registry, how we have been working on it for about 18 months, and how we have 12+ pages of text now most of which has been discussed previously. We can talk about any of that content today, but let's start off with the recent changes)

[edit]

New syntax for globals and markup

(Jon describes the new syntax, proposed by Yehuda at the face-to-face meeting, where we now have to_approve: and to_acknowledge:, both of which have child properties globals: and markups:. The markups property is expressed using CSS selector syntax)

Jon: One of the things I noticed when updating the Registry wiki page is that the attribute selector syntax can be confusing. Lightstreamer has a 'lightstreamer' attribute, so the entry reads as markups:["['lightstreamer']"], which is bracket, quote, bracket, quote, content, quote, bracket, quote, bracket. Is this a problem?

Kin: Spry has the same requirement as Lightstreamer. We have put up a Registry entry. Some of our attributes can go on multiple elements. They have to be listed separately.

(discussion about how CSS syntax allows for saying an attribute goes on any element or that an attribute goes on a particular element.)

Kin: DTDs offer more flexibility in that you can list a set of elements and then refer to that set.

Jon: There is high value in leveraging an existing standard than inventing some new syntax.

Alex: I'm fine with the syntax as is. But what do you get out of it? Let's say I register a CSS selector. Does it mean that my toolkit owns all elements that match that selector or is it just an indicator that I use those attributes and elements? The real question is ownership. How does this address this issue?

Jon: The syntax right now is just an indicator and doesn't show ownership.

Kin: The syntax is just a warning to developers.

Alex: We need a way to specify ownership of a node.

Jon: If we added another value within the Registry for ownership, what would be call it?

Rich: Isn't what is going is that you are modifying a node in a potentially destructive way?

(some discussion about potential names: manage subtree, own subtree, exclusive control, assume ownerhip, ...)

Jon: Let's move the discussion of names onto the email list. I'll make a proposal. But first let's make sure everyone agrees with adding a new field in the Registry. Any objections?

(no objections)

RESOLUTION: Add a new field to Registry to reflect which nodes a toolkit "owns"

RESOLUTION: The name of that new field will be discussed on email

Jon: Just want to be clear. The above field is additive and we will retain the 'markups' feature that is already in the Registry.

Kin: Sounds good.

Jon: One more change to object to the bracket, quote, bracket, quote potential confusion. Any objections to keeping this?

Kin: Less of a problem if the entry is formatted in particular ways

Jon: OK, no objections. But it makes sense to add some words to the Registry writeup to alert developers.

RESOLUTION: Add words to Registry wiki page to warn about potentially confusing syntax with attributes (i.e., bracket quote bracket quote)

[edit]

Wildcards (asterisks) within 'markups:'

(Jon describes potential need for wildcards in classnames. Some Ajax toolkits might have many widgets and many different classnames to style those widgets. Some toolkits might be open source with a decentralized development process and therefore difficult to keep track of all of the classnames in use.)

Kin: Using jQuery as an example, maybe I would want to see what classnames are currently in use by other parts of jQuery

Bertrand: Wouldn't that be the responsibility of the jQuery community to coordinate things within their community?

Jon: Agreed. Our Registry should be at the granularity of Ajax toolkits and affairs for particular toolkits shouldn't be in our Registry.

Alex: There is some syntax in CSS for classname wildcard, as in [class^="foo"]. There is also a *=, but not for substring matching

Jon: How about allowing * as part of the classname, where we extend the CSS syntax

Alex: We (dojo) had to do that for the same reason

Jon: What do people think of that?

Rich: How about generalizing this so that any of the markup types can use *

Alex: CSS also doesn't allow for attribute name wildcarding

Jon: Oh, I didn't realize that

Alex: Same with tagnames

Jon: OK, * allowed in attributes, elements and classnames.

Bertrand: Is there a worry about conflicts with future versions of CSS?

Alex: Yes, so we should propose this back to CSS

Jon: Yes, we should make them aware, but the future compatibility issue isn't a killer problem. We can point to CSS3 selectors and say we add "*". If CSS4 Selectors comes out with an incompatibility, that's not the end of the world. We can continue to point to CSS Selectors. We aren't parsing our syntax with the browser engine.

Jon: Any objections to approving wildcards for attributes, elements and classnames?

(none)

RESOLUTION: Asterisk (*) is allowed in attributes, elements and classnames. (Presumably only at end)

[edit]

Proposed process going forward

Jon: Here is what I'm thinking. We resolve the name of the new property via email. Then we do +1 voting within this committee over email. Then announce to public at Ajaxian and sys-con and give a small number of weeks for feedback. If everything OK after this public period, then we push out the approved version 1 of the Registry.

(no comments, no objections)

RESOLUTION: Approved Jon's proposed process going forward (see detailed minutes for description)

[edit]

Multiple XML namespaces

Kin: I raised an issue about what to do if a product uses multiple XML namespaces. Backbase does this. It is possible that prefixes and namespaces might collide. Do we need to add information to the Registry for this?

Jon: Do they use proper XML namespacing with xmlns, or just use prefixes as part of HTML

Kin: Proper XML namespacing.

Bertrand: In these scenarios, who puts the xmlns attribute into the DOM? The application developer or the toolkit? For us (MS Ajax) it is the application developer who is responsible for that.

Jon: I have suggested a simple alternative. Instead of adding new fields for XML prefixes and namespaces, just tell people that they should describe their use of prefixes and namespaces in the comments field.

Bertrand: I don't think there is a good way to do this. This can get complex.

Jon: Given the complexity possibilities, I would propose we postpone anything in this area until version 2 so we can get a better feel of how best to address this requirement, and use comments for version 1.

Kin: OK, but I don't understand why this can be complex.

RESOLUTION: Add text to Registry wiki page telling developers to describe their XML namespace prefixes and namespace URIs within the comments field

Retrieved from "http://www.openajaxalliance.org/member/wiki/Interoperability_Minutes_2008-04-23"
Personal tools