Re: url params et al

Erik,

> It would be a huge drag to prevent img/@src to work, because img/@src is
> a big use case for AVTs IMO, and users will not understand easily why
> a/@href would work but img/@src not!

My point was not that we shouldn't have this functionality, but that
we need to work out how we will get it.

My proposal was just an opener. I'm saying that if we take as a
starting-point that AVTs cannot be used prior to the DOM load event
then at least we have a clear dividing line for which attributes are
in and which are out. The reason I believe this to be important, is
that differentiating attributes on the basis of their *type* is not
good enough--some XPath expressions work fine as AVTs, and some simple
text values don't work at all. You might as well pick all attributes
that begin with a vowel.

Now, once you've drawn some line in the processing (it doesn't matter
where, really, it's just to get things rolling) then of course we can
agree that allowing AVTs in img/@src is desirable. (Although I
disagree that authors don't understand the difference between
traversing a link on request and one on load.)

But with the clear line having been drawn, the question becomes not
"it would be terrible if we couldn't use AVTs in img" (that's a
given), but "how do we move this dividing-line backwards in time so
that images can be loaded from URLs that are soft"? I'm not saying it
can't be done, but I am saying it's work that needs to be done.

The reason it's tricky to move it before "DOM load" though, is that
there is no connection between the XForms events that concern the
model, instances, and so on (such as xforms-ready) and the HTML
loading sequence (which loads scripts, images, objects and so on).
This means that were we to choose "xforms-ready" (for example) then we
have nothing that says all images haven't already been loaded by the
time "xforms-ready" is complete.

Unfortunately, as much as we want this functionality, we can't just
simply assert it. So to go back to what I thought was the agreed
goal--to find some common ground for implementation, *not* to write
spec-ready text--I would still suggest that a first wave of
implementation work could be to implement as AVTs any attribute that
is used after the document has been loaded. And then from there, see
whether we can use our experience to help us provide the same support
for further attributes.

And it may actually be the case that img/@src cannot support AVTs as
things stand. I wouldn't lose any sleep over that, or waste too much
time with it, since we have xf:output with @mediatype, and for that
the loading sequence and relationship to instance data is clearly
defined. (And we're using xf:output with @mediatype values of video
and audio too, so we have a clearly defined way to support h:object
aswell.)

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 Tuesday, 29 August 2006 10:07:41 UTC