XHTML Applications and XML Processors [was Re: xhtml 2.0 noscript]

HI Jim,

> >The second is that we actually process the script
> >at the same time as loading the document in the XML processor.
>
> Let's widen the situation away from XHTML - to include XML Events, XML
> Events are a generic process, this means that an XML processor that wanted
> to use it would need to support them, these break the idea that what arrives
> onload is the same as arrives before unload, there's no seperation from
> XHTML/XML here.

But I don't think you'd say that the XML Events processing is part of
the 'XML processor', in the sense that the term is used in the XML
spec. At least at a logical level, it would be a different layer, even
if some processor that you installed and ran supported this.


> I'd also be concerned by your suggestion that an XHTML DOM need not exist
> until after a document has fired its onload - when we know than an XML DOM
> needs to be - the idea that an interface changes post load is worrying, and
> not something very implementable.

I was using the term 'load' in a general sense--I don't think I talked
about the onload event as such. To be more precise I'd see the process
*conceptually* as follows:

* the XML processor passes a complete DOM to the XHTML processor;
* the XHTML processor starts using this DOM:
   * attaching event handlers from XML Events;
   * running any inline scripts;
   * loading any images and other resources;
   * and so on;
* the 'onload' event is then dispatched, right at the end.

Now, the reason I say 'conceptually' like this, is that you could
write a browser that has SAX on the input stream, and passes parts of
the source document to the XHTML processor the moment it gets them.
But this XHTML processor would need to do things like queue up event
registrations that apply to nodes that don't yet 'exist' until those
nodes do 'exist' (i.e., forward references):

  <action ev:event="layegg" ev:observer="chicken">
    ...
  </action>

  <div id="chicken">
    ...
  </div>

Of course it's easy enough to implement such a thing, but the point is
that by doing so we've made the behaviour of a SAX-based and a
non--SAX-based processor effectively the same. In short, I think we'd
need to define things in this 'conceptual' way so that we get
interoperability, even if implementers add optimisations.

Interestingly enough, we have discussed the fact that XML Events
doesn't actually define precisely *when* its listeners get registered,
and you have reminded me that we should sort that out. In my view it
implies some kind of 'document ready' event to be defined over in DOM
3 Events or something, that could then be used as the hook for such
things. (The same goes for things like loading images.)


> >Given this 'architecture' or 'processing model', it means that any
> >executions of inline document.write() calls will take place after the
> >entire document has been loaded, and so will not be modifying the
> >*initial* document.
>
> This interpretation though knocks out an awful lot more than just
> document.write - it also knocks out the majority of user agents - including
> all the XHTML ones I had to hand - you've got my test case.

What do you mean by an XHTML user agent, though? There are those that
'understand' XHTML 1, that's true, but are you talking about ones that
actually process the XML as XML? Which ones would you include?


>  Whilst the test
> case I posted does rely on one thing which is not currently standard, it is
> being standardised by the Web API working group, I hope you will raise this
> issue there if you feel the issue is relevant.

I don't see anything wrong with what you did in your earlier post; all
I'm doing is saying that I don't think there is any scenario where you
can say that your script is executed *before* the document is fully
parsed that makes for interoperable behaviour. (With the same rider
that saying "fully parsed" does not rule out optimisations based on
some data being available earlier through mechanisms like SAX.)


> (I would rely much more on document.write not working because the spec says
> it only works after a document.open rather than trying to argue the theory
> of XML models, which whilst I can see the argument, it has to many
> implications beyond document.write which are required on the web.

But in some ways you could say that is why it needs to be pinned down.
Let's put it the other way round; if I were to implement an XHTML
viewer by first loading the XML into a DOM and validating it, before
passing it through to a renderer, what is wrong with that? The problem
is that if we allow a processor to *choose* to run some of the script
before the document is completely available (conceptually), then we
rule out this 'naive' approach.

Far better then to say that the approach is that the complete document
should be 'available' before the DOM can be modified. That doesn't
rule out optimisations like loading images and resources before the
document is fully parsed.


> >This means that the same document will *always* be
> >loaded into *any* XHTML viewer, and it is only once loaded that script
> >elements could be processed and make a difference. There is therefore
> >no need to support <noscript>, since during the initial loading
> >process there are no 'alternative routes'.
>
> As we can see from the previous testcase - or from any XML document using
> XML events, the above is not sustainable.

I'm not sure why. It's a case of defining when the listeners are
registered, and I think the only way we can make it consistent is if
they are registered on 'document ready'.

I'm not at all saying that everything I describe here is already
defined in XHTML 2, XHTML 1, XML Events, etc.--so it's not a question
of (mis)interpretation. Instead I'm *proposing* that this is how it
could be done, in order to allow for consistency and interoperability.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Saturday, 29 July 2006 18:00:24 UTC