Markup Minutes 2006-07-13
From MemberWiki
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