Markup Minutes 2006-07-13

From MemberWiki

Jump to: navigation, search

Contents

Minutes from Declarative Markup committee teleconference July 13, 2006

Attendees

  • Alex Russell <alex@dojotoolkit.org>
  • Anil Sharma <anil@vertexlogic.com>
  • Coach Wei <coach@nexaweb.com>
  • Gustavo Munoz <gustavom@jackbe.com>
  • James Margaris <jmargaris@nexaweb.com>
  • Jon Ferraiolo <jferrai@us.ibm.com>
  • Lindsey Simon <lsimon@finetooth.com>
  • Ted Thibodeau <tthibodeau@openlinksw.com>
  • Vivienne van der Vooren <vvandervooren@seagullsoftware.com>
  • Phil Berkland <berkland@us.ibm.com>


Absent

  • Adam Peller <apeller@us.ibm.com>
  • Alejandro Escalante Medina <alejandroe@jackbe.com>
  • Charles Lowell <cowboyd@thefrontside.net>
  • Chuck Ames <CAmes@seagullsoftware.com>
  • Dave Johnson <djohnson@ebusiness-apps.com>
  • David Frankel <david.frankel@sap.com>
  • David Temkin <temkin@laszlosystems.com>
  • Eddie O\'Neil <ekoneil@bea.com>
  • Eric Nguyen <ericn@mercedsystems.com>
  • Erik van Dongen <evandongen@seagullsoftware.com>
  • Javier Gallego <Javier.Gallego@softwareag.com>
  • Jeremy Chone <jchone@adobe.com>
  • Jim Grandy <jgrandy@openlaszlo.org>
  • John Crupi <john.crupi@jackbe.com>
  • Joonas Lehtinen <joonas.lehtinen@itmill.com>
  • Jorge Taylor <jotaylor@adobe.com>
  • Ken Fyten <ken.fyten@icesoft.com>
  • Kin Blas <jblas@adobe.com>
  • Kingsley Idehen <kidehen@openlinksw.com>
  • Marc Englund <marc.englund@itmill.com>
  • Mark Schiefelbein <mark@backbase.com>
  • Michael Peachey <mpeachey@tibco.com>
  • Ruben Daniels <ruben@javeline.nl>
  • Sami Ekblad <sami.ekblad@itmill.com>
  • Steven Pothoven <pothoven@us.ibm.com>
  • Vincent Hardy <vincent.hardy@sun.com>
  • William Shulman <will@mercedsystems.com>

Agenda

  • Review updated markup mixing proposal from Nexaweb (originally authored by Nexaweb -- thanks James and Coach for the great work -- with a few interspersed comments from Jon Ferraiolo)
  • Assuming we want to have a standard set of JavaScript source for the OpenAjax hub, how should that code be developed:
    • As an open source project within the OpenAjax Alliance?
    • Or do we partner with one particular external and neutral open source project which develops the official reference JavaScript code?
    • Or do we just define a solid spec and expect that various toolkit providers will find a way to implement that spec and include it as part of their respective toolkits?

Topic: Review updated markup mixing proposal from Nexaweb

Link: Markup Mixing Nexaweb IBM 20060712

Jon: Goal of this meeting is to reach consensus on this proposal. My issues on were on two issues, "single dom" vs "dual dom", and the fact that todays browsers have imperfect support for namespaces.

Alex: Spry has solution using namespace on tag attribute, dojo is similar but also has classname

Jon: what about dojotype attribute

Alex: causes w3c validation problems

James: I folded this into the document to handle all cases. Arbitrary xml tag wont work well in all browsers. Should support namespaces as much as possible but in current time frame wont work in every browser

Jon: Dojo offers 3 approaches - namespaced attribute (foo:bar), use class attribute (class="widgetname"), or simple attribute (dojotype="")

Alex: not a great solution for developers. thats what 1st pass parser normalizes

Jon: what 1st pass parser do

Alex: folds names, etc, almost what is being discussed here

Jon: dot it remove things from dom?

Alex: no

Jon: implicit requirement we should allow 3 approaches alex mentioned. A fourth approach would be to make a function call to attach an element name to a toolkit.

Lindsay: what means?

Jon: developer should be able to use all approaches, We support HTML, today's browser, some developers want to use w3c validator, should be inclusive, can use validator

Coach: meaning XHTML validator?

Jon: XHTML, havent used it for a few years

Coach: is XHTML

Jon: thats why no dojotype attribute

Alex: HTML spec says ignore unknown attributes

Jon: what happens on dojotype attribute and W3C validation?

Alex: it complains

Jon: what about conflicts using the class attribute and different styles ?

Alex: prefix class name with "dojo", html allows multiple values for class attribute.

Jon : what are the pros/con of using "oa:type" option?

Alex: is ok

Lindsay: some validators will complain

Alex: class name no less a Kludge

Lindsay: lets throw the ideas out there, let users choose

Jon: we are doing the first pass, and taking our best shot, we go to public and get user feedback and adjust, but should try to get as close as possible. Whether to have one, many, or both comes into the page scanning issues. If a OpenAjax hub did a top down scan, it either looks for class attribute, or for "oa:type", comments? If we support both, there is more checking that has to be done.

Jon: dojo does top down traversal by default, but has options to allow for better performance, this approach make sense for Openajax hub.

James: in the proposal mentioned ids, allowing user to getElementbyID, user set hint to say what option

Jon: that what i think, Openajax page scanner would be configurable, either declaratively or procedurally

Alex: think its a good idea, need to decide what parts are noncontroversial enough to standardize One approach to interop is to be hands off- ignoring markup entirely, this is "harness" approach (look at everything) There is room for discussion here

James: need to elaborate the differences in the proposals. In the Dojo-Tibco proposal, must scan for "oa-embed". In my proposal less for user to type.

Ted?: oa-imbed was not meant for client, more for the server or xslt processing, would be removed before it got to client, so no parsing

Jon: we care only about client - what runs in the browser

Alex: another motivation is multiple toolkits in the same page, they all should not have to scan the entire document

?: that is a real problem

Jon: this is what we are trying to address, in order to optimize page scanning, openAjax hub needs to scan so every toolkit doesnt have to. default scan is for openajax hub, with extensible hooks for toolkits to define what they need

RESOLUTION: Openajax hub in charge of page scanning.

coach: makes sense

Vivienne: makes sense

ted: reasonable

Alex : fine

Jon: what should OA hub search for? should multiple items or single item be search for, searching for more items affects performance

coach: enable developer to configure what to search for i.e. "oa:type" or "foo:bar"

jon: on approach is openajax hub does no search by default, as toolkits are loaded, they say what to search for

Phil: this means that toolkit needs to be loaded before search

jon: processing model I was thinking of toolkits load by "head", scan done on "onload" event, some toolkits can load more of themselves later

coach: there are 2 scenarios - one are toolkits which can dynamically load (no problem), and those which have no dynamic loading, for those it is up to the page developer to insure everything is there.

jon: makes sense, it is toolkit user responsibility to make sure things are loaded

?: is reasonable

jon: presented one approach possible approach = hub doesnt do anything by default,


James: we are mixing issues - what tags the toolkit supports, and the actual scanning options. Just because a toolkit is being used, it doesnt mean there are any tags for that toolkit in the page. Actual scanning depends

Jon: good point - toolkit developer puts javascript on website, dont kow

James: toolkit defines what to look for, user knows what algorithm to use for search

Jon: opinions ?

Alex: leave it open, scan everything , can be changed later

ted :ok

Lindsey: Jon's comment in proposal about not destroying dom, should this be addressed?

Resolution: openajax position is not destroying the dom is better, it is a "Should", not a "must"

James: its does not matter for the proposal, it is up to the element handler (toolkit)

ted  : there can be secondary handoff if there are embedded from other toolkits

James: the top level is automatically handled, if a subtree has another toolkit embedded, it is up to the toolkit to handle using a helper function.

Jon: I like that approach, it is similar in the standards world to xslt, where "applytemplates" can be done anywhere to recurse into subtrees, preservation of preserved content is up to the toolkit, but our best practice is to preserve

Ted: there may need to be some flags to indicate if element was handled - A imbeds B imbeds A

James: that case should be handle by rescaning subtree

Ted: may be looking at external part of the dom

Jon: the dom is wide open, anyone can change anything

coach: not the responsibility of the openajax hub

james: if the toolkit modifies outside of it's subtree, they should know what needs to be rescaned

Jon: could say that openajax toolkits only work on their subtree, and use a notification mechanism if changing outside the dom

Action Item: James, Jon, and Coach will work on the updating the document based on the comments from this meeting

Action Item: James will begin implementing javaScript, looking at Alex's code from 5/27. It should be simple, around 300-500 Locs. Anil is available to assist with code or QA

Personal tools