From MemberWiki

Contents 1 Minutes from Declarative Markup committee teleconference June 1, 2006 1.1 Attendees: 1.2 Agenda: 1.3 Topic: Logistics 1.4 Topic: Overall focus of this committee 1.5 Topic: Next steps 1.6 Topic: XML compliance and XML namespaces as best practice? 1.7 Topic: CDF compliance? 1.8 Topic: New tags for widgets vs. new attributes on HTML widgets and relationship to degradability? 1.9 Topic: How important is it to allow scripting against the original XML tree? 1.10 Next meeting:

Minutes from Declarative Markup committee teleconference June 1, 2006

Attendees:

• "Adam Peller" <apeller@us.ibm.com>
• "David Frankel" <david.frankel@sap.com>
• "Jon Ferraiolo" <jferrai@us.ibm.com>
• "Javier Gallego" <Javier.Gallego@softwareag.com>
• "Eric Nguyen" <ericn@mercedsystems.com>
• "John Janetos"
• "Alex Russell" <alex@dojotoolkit.org>
• "Phil Berkland" <berkland@us.ibm.com>
• "Jeremy Chone" <jchone@adobe.com>
• "Coach Wei" <coach@nexaweb.com>
• "Ken Fyten'" <ken.fyten@icesoft.com>
• Gustavo Munoz Jackbe (for John Crupi)
• Jim Grandy (for David Temkin) director of open laszlo

Absent:

• "David Temkin" <temkin@laszlosystems.com>
• "Eddie O'Neil" <ekoneil@bea.com>
• "John Crupi" <john.crupi@jackbe.com>
• "Mark Schiefelbein" <mark@backbase.com>
• "Michael Peachey" <mpeachey@tibco.com>
• "William Shulman" <will@mercedsystems.com>

Agenda:

• Timing and frequency of meetings. Every week or every two weeks? This time slot or an hour earlier?
• Logistics: IRC, email lists, wikis, etc.
• What activities should this group pursue initially. For example, do we want to focus on simpler, low-hanging fruit issues initially similar to the strategy being used by the Interoperability group, or do we want to focus initially on higher ambitions, such as XAP or maybe even something like a XUL.
• What is the relationship between the Markup group to the Interoperability group? (Note: We need to make sure everyone is aware of Alex Russell's proposal to the Interoperability group: http://alex.dojotoolkit.org/oaa.tar.gz Also, for reference, I copied the minutes from last week's Interoperability meeting to the bottom of this email.)
• Start on use cases and requirements.
• Time permitting, what is the relationship of XAP to the work of this committee? (http://wiki.apache.org/incubator/XapProposal)

Topic: Logistics

Resolution: Phone calls every two weeks at this same time slot: 9amPST/12pmEST/6pmParis. (However, our next phone call will happen one-time-only on Wed June 14 in the same time slot.)

Resolution: IRC channel will be at irc.freenode.net on channel #oaa-markup.

Jon: Other news. Email lists and wiki are coming soon, within a week or so.

Topic: Overall focus of this committee

Jon: Do we want to take a low-ambition approach similar to what the Interop committee has decided to do?

Eric: What would that look like?

Coach: Makes sense to have low-ambition objectives. Focus on markup interop. Best practices so that multiple markups can interoperate and integrate with visual tools.

Jon: I agree with Coach.

Alex: Yes, but this is not tremendously implementable now.

Coach: If you talk about best practices, issues are whether it is XML compliant, meaning can XSLT operate on it, whether CDF compliant.

Jon: CDF is about combining arbitrary XML grammars in general but also combining XHTML with SVG in particular. Right now this is driven by browser companies, particularly Mozilla and Opera.

Phil: Toolkits must have their own XML namespace. I don't believe Laszlo does this.

Jim: That's correct, but XML namespaces is a reasonable direction.

Jon: Visual tooling compatibility requirement - must or should?

DavidF: What would be a way to say this?

Coach: Would say that markup language must be plugginable into tools such as ATF or Eclipse

Jon: Jeremy, wouldn't Adobe be interested in this, to allow 3rd party widgets to plug into Adobe tools?

Jeremy: Good discusion but a huge task. Yes we are interested. That is why we are on the call.

Coach: Good subject: what's the positioning of the subcommittee? What we agreed in SF is that we don't intend to be a standards organization like W3C and we don't want to create a new UI markup language.

Jon: Proposal: We focus on interop at the XML level in partnership with Interop committee.

Jeremy: Make perfect sense.

Phil: ATF - we might have a schema to define markups for ATF to recognize.

Jeremy: Makes sense.

Jeremy: Need to make sure we are clear about what the group is not about.

Jon: Probably never compete against W3C language efforts such as what is happening in WebFormats Working Group. Probably never compete against vendor languages like MXML, LZX and Backbase.

Jeremy: What problem are we solving? An XML UI language?

Coach: Focus on lower ambitions, low-hanging fruit.

Jeremy: I agree.

Coach: Focus on best practices guidelins on how an XML component can integrate into other components and visual tools

Resolution: We are not defining a full markup language but instead component interoperability at the XML level. Goal is plug and play with 3rd party components and visual tools.

(No objections to this.)

Jeremy, Jim: Yes, good direction.

Jon: Also, we should work in parallel and in collaboration with the Interop committee.

Jeremy: Yes.

Topic: Next steps

Jon: I suggest that we devote the next couple of teleconferences to fleshing out use cases and requirements. In a group setting, it is important to agree on requirements before delving deep into technical solutions.

Jeremy: Yes, good way.

Topic: XML compliance and XML namespaces as best practice?

Alex: IE6 doesn't provide any advantages. Allows content but doesn't take advantage of it.

Jon: I am assuming the compliant OA content must use namespaces, but doesn't mean that browsers have to anything in particular with it. Alex, any problems with browsers if content is proper XML?

Alex: Doesn't blow up. But not all content nodes will render correctly.

Gustavo: Server side can compile into whatever is needed.

Coach: This is an implementation detail how to work around browser deficiencies. Some solve on server. Some solve on client.

Jeremy: Should really focus on HTML+JS+XML. Server-based solutions need to be optional. Needs to be solvable on client side using HTML+JS+XML.

Coach: XML namespaces shouldn't require server-side adaptation.

Jeremy: Yes, if it is true that there is a workable client-centric way that is cross-browser.

Jon: Can you do this with IE6?

Alex: Generally, but with some constraints.

Gustavo: Need to understand what we consider to be target browsers.

Jon: Yes. Let's discuss this as part of discussion on requirements.

Topic: CDF compliance?

Jon: CDF defines two levels. General framework for combining different visual-oriented XML and specific rules for combining XHTML+SVG. We need to look at this in more depth. Have to decide what parts are applicable and what parts are not. Hard to ignore the relevant parts as this is a W3C standards and browser vendors seem to be engaged.

Topic: New tags for widgets vs. new attributes on HTML widgets and relationship to degradability?

Jon: One aspect of degradability is whether something reasonable should be done if JS is turned off.

Jeremy: Very good to have this approach.

Jon: Dojo offers two markup approaches. New tags or attributes (dojoType=) on HTML form elements. Both translate into the same JavaScript under the hood.

Alex: Don't want this group to break backwards compatibility or force other toolkits to break themselves

Jeremy: Don't want to do anything to break existing toolkits

Jon: But if we can't do anything that can't break any toolkits, we can't do anything.

Jeremy: Yes, but still a good goal. Need to make tradeoffs.

Coach: Not breaking compatibility: this is more of an implementation issue than a markup issue.

Alex: Big concern for end users.

Coach: Yes, but not sure how degradability relates.

Alex: Could provide an OAA XSLT that would be you a degradable view. Could be up to toolkits whether they would choose to use this. Just a brainstorm.

Jeremy: We should see if we can accomplish this. Would be a nice result.

Gustavo: A bunch of options to transcode. Server, client, XLST, etc.

Topic: How important is it to allow scripting against the original XML tree?

Coach: XAP feels this is important - ability to script against original XML. But can see why other implementations don't want to keep the original XML.

Gustavo: In some cases, doesn't add value, but in other cases, it is needed.

Jon: Keep in mind XBL at W3C. Shipping in Mozilla since 1998, proposed to W3C in 1999. On back burner for 5 years. Now active work is happening again. Also keep in mind XAP at Apache.

Jeremy: But XBL is not in IE and won't be anytime soon. Could have a toolkit that emulate this in IE or maybe we wait until IE supports it.

Coach: In XAP, we provide functionality in IE via JavaScript.

Next meeting:

(One time only) Next phone call will be on Wednesday instead of Thursday

Agenda: Roadmap and schedule, Use Cases and Requirements