Re: Updated draft of XML Data Island Module

Mark -- thanks for the comments...very rapid response and very timely, we
discussed most of them during today's telecon, see
http://lists.w3.org/Archives/Public/public-forms/2008Dec/0019.html for the
draft minutes.

Briefly:

1. We'll go back to the Data Instance terminology since it corresponds most
closely to the element and event naming used in the module.

2. We do think there's an easy way to extend the module even in its' first
version to support some limited JSON function -- particularly for accepting
JSON data both for inline instance content and for remote loading using src
and resource attributes.  We'd continue to build a DOM representation and
support IDL access only as such in the first version.  But at least we
could allow for an XML abstraction over JSON including script access using
a library such as E4X (allowing what might be a more convenient expression
language for AJAX developers).  Future versions of the module could then
provide the inverse function, namely JSON/JS abstractions over a variety of
content types including subsets of XML where desired...Flex does this type
of thing today.

3. I took an action item to look at the existing load event to see if it
makes sense for us to use that rather than data-instance-ready.

4. We thought having both the language-neutral IDL and normative language
bindings (including JS) in the format you describe would be the way to go.

5. There's no default/container provided loading lifecycle for the data
instance module...so load() seems to be the right name.  When used alone,
there's no containing context to drive loading implicitly.  We could give
guidance, of course, that in HTML/XHTML the module should register itself
for document or content ready and call load() but that's a host-language
specific pattern (though of course an important one).  When used with the
Model module, I had thought that load() would be called by model
processing, though it could still be done in a more bottom-up fashion as in
the raw HTML case just mentioned.

We moved the reset() function out of this module at the F2F since we didn't
want the lowest level data instance module to have to manage a cache of the
originally-loaded content...this is now in the model module I believe.

Thanks, Charlie

Charles Wiecha
Manager, Multichannel Web Interaction
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, N.Y.  10598
Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
wiecha@us.ibm.com



                                                                                                                                              
  From:       "Mark Birbeck" <mark.birbeck@webbackplane.com>                                                                                  
                                                                                                                                              
  To:         Charles F Wiecha/Watson/IBM@IBMUS                                                                                               
                                                                                                                                              
  Cc:         public-forms <public-forms@w3.org>                                                                                              
                                                                                                                                              
  Date:       12/10/2008 10:38 AM                                                                                                             
                                                                                                                                              
  Subject:    Re: Updated draft of XML Data Island Module                                                                                     
                                                                                                                                              





Hi Charlie,

I'll not be able to make the call today, so I thought I'd forward some
comments.

1. It would be good to have a consistent naming/prefix pattern throughout
these modules. So in this case the spec is called "data islands", whilst
the event names begin "data-instance". I'm not saying which name is better,
but I'm just making the point that as we add modules it would be quite good
for developers if the naming matches.

(Having said that, I don't think we whould have the prefixes...see below.)

2. The editorial note says that we want to have non-XML data islands in the
future, and that's why events are named the way they are. But I think if
that is a serious goal, then the spec name should change. (As it happens, I
think we might fall foul of being too flexible, and it might be better to
let the future take care of itself, and focus on XML now.)

3. I think the "data-instance-ready" event might be mappable to the "load"
event from DOM 2 Events. I haven't double-checked, but my recollection of
the "load" event is that it's related to pretty much any object that has
completed loading, whether it's an image or whatever. So I think it would
be appropriate to use it here.

(Note also that DOM 2 Events has an "error" event, too.)

4. Do we need get/setInstanceDocument()? Why not just have a property, such
as .document? It's a minor thing, and probably all a matter of taste, but
since any use of this method will almost certainly be to do things like
this:

  if ( instance.getInstanceDocument().documentElement ) {
    ...
  }

then why not allow this instead:

  if ( instance.document.documentElement ) {
    ...
  }

To me it feels more consistent with other specs.

5.  Since the document should have been loaded already, then load() is
misleading. If it's going to *reload* the document referred to by the URL,
then I think it should mirror the XForms "reset" action, and could probably
be called reset().

I think we still need a load() method, and that it should take a URI
parameter.

7. I'm not convinced we should refer to things like how to control
namespaces using XForms submission, or that an event might be interpreted
as a fatal error in XForms; My preference would be to keep this spec as
lean as possible (and of course it might not always be a fatal error in
XForms).

Regards,

Mark

On Wed, Dec 10, 2008 at 9:48 AM, Charles F Wiecha <wiecha@us.ibm.com>
wrote:
  For our telecon discussion today...Charlie

  (See attached file: index-all.html)

  Charles Wiecha
  Manager, Multichannel Web Interaction
  IBM T.J. Watson Research Center
  P.O. Box 704
  Yorktown Heights, N.Y. 10598
  Phone: (914) 784-6180, T/L 863-6180, Cell: (914) 320-2614
  wiecha@us.ibm.com





--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)