RE: [wsia][wsia-requirements][R602]

[Sean Fitts <sean@crossweave.com>]

Not to be overly picky (because I agree with the general point), but
scripts
of the form outlined below actually can be transformed in a general
way
without the need to perform flow analysis or know anything about 
the
semantics of the script itself.

The ones that are more bothersome are scripts of the form:

<script>

        

document.write("<font
size='6' color='green'>Portlet1</font>");
</script>

If, as a Consumer, I want to customize the size and/or color of the
font,
I'm out of luck without some help (as you point out).  Of course,
even if 
this is given to me in nice, clean markup, I don't really know the
significance 
(at the application level) of the <FONT> element, so I still need
something
that tells me that this is the FONT used to display part numbers or
sale
prices or ....

To me, it seems like a matter of degrees, not true difference. 
Which is
why I hesitate to support the additional wording.  It takes pains to
draw a 
distinction between script and markup which, although it supports a 
common perception, isn't really there.  Also, I think the emphasis
on action 
routing is misplaced (don't get me wrong, that's important too, but so is
general customization).

As to the potential solution list, I think I agree with the
choices.  Option 1
is not an option in this case (the capability is much too core). 
Options 2
and 3 come back to the age old "who does the work"
question.  To me the
only correct answer is "yes", since both approaches have pluses
and minuses
and I believe that we will want to support distribution of this work
throughout
the network (from Producer to Consumer to intermediaries).  I don't
think we
want this requirement to favor one topology over another (and I don't
think
it does).

Sean

At 06:38 PM 5/8/2002 -0400, Eilon Reshef wrote:

My thought was around people that use scripts like this:
 
<script>
var target = "http://" + gMyDomain + "/mypage.rgb?page=" + document.form[1].pageNumber.value;
 
document.location = targert;
</script>
 
My intent was to formulate a part of the requirement that clearly states that WSIA cannot expect Consumers to automatically rewrite this action to point back to the Consumer.
 
Does this make sense as the intent of this part of the requirement?
 
As for a proposed solution, one can consider three options:
1. Disallow such cases and other such constructs (which is always the last resort).
2. Define a meta-language that does not require changes to the script (assuming it's a script that was written beforehand), and tries to capture the replacement locations externally (a-la adaptation). However, the halting problem (;-) does argue that there will still be cases that the external language won't be able to address.
3. Ensure that enough information is passed to the Producer so that when it either writes new applications or when it needs to adapt cases like this, it would be technically possible.
 
Any thoughts?
 
Eilon

-----Original Message-----

From: Sean Fitts [mailto:sean@crossweave.com]

Sent: Wednesday, May 08, 2002 5:57 PM

To: Eilon Reshef; wsia@lists.oasis-open.org

Subject: RE: [wsia][wsia-requirements][R602]

At 04:51 PM 5/8/2002 -0400, Eilon Reshef wrote:

I think I see your point (I thought of modification as semantic versus syntactic), how about the following wording (which still puts the Customization issue aside):

One small tweak, the modifications may be semantic, but the semantics are

largely implied and will likely need to be described externally (ala the adaptation

description in WSXL). 

I guess I don't see a lot of difference here between this type of modification and

general markup modification.  Both contain semantic information, both require

some sort of locator to identify the sections implementing a given semantic

operation, and in both cases, the semantics are opaque.

This specification must support common Presentation formats, which are in use today in Net-enabled applications. In particular:

1. It MUST support Presentation Fragments in HTML, XHTML, XML and WML.

 

2. It MUST support JavaScript as an associated scripting language. Such support MUST include a way to support Actions triggered by scripts. However, it SHOULD NOT be assumed that the Consumer is aware of the semantics of scripting elements.

Given the parallel between semantics of scripting elements and semantics

of other elements (such as markup and/or actions), I still don't see the need

for the second statement.  However, in this form it seems a lot more benign

(at least to my eye).

3. It SHOULD support embedded binary presentation elements (e.g., Flash, Applets, etc.). 

[Optional/Debate: Such support SHOULD provide a way to support Actions triggered by such elements.]

However, it SHOULD NOT be assumed that the Consumer modifies the binary elements in any way.

 

I personally think it makes sense to favor a single technical approach that captures both (2) and (3), but I also don't see it as a high-level requirement but rather as a technical preference.

Could you elaborate on this?  I'm not sure I understand.  Thanks.

Sean

-----Original Message-----

From: Sean Fitts [mailto:sean@crossweave.com]

Sent: Wednesday, May 08, 2002 2:14 PM

To: Eilon Reshef; 'Rich Thompson'; wsia@lists.oasis-open.org

Subject: RE: [wsia][wsia-requirements][R602]

At 01:55 PM 5/8/2002 -0400, Eilon Reshef wrote:

I am not suggesting that the Consumer is not allowed to change JavaScript, rather the suggestion is that we wouldn't assume that it should. To me, that's because correctly analyzing code constructs (in any language) without executing them is anywhere from hard (from a practical perspective) to impossible (from a theoretical perspective, as Theory of Computation shows).

I don't see a connection between supporting modification of JavaScript

(which I agree is an open issue) and the need to support complete,

path wise analysis of it.  Leaving the halting problem aside for a bit, it

would seem possible to extend the Adaptation Description Language

proposed by IBM to include JavaScript modifications along with XML

and CSS ones.

This is not to say that WSIA can't define an interface that uses JavaScript (e.g., I assume the committee may decide to define JavaScript functions, events, etc.), but I guess that the question is can we require the Consumer to analyze JavaScript code to support action routing, for example?

Again, I don't see how leaving the second sentence out leads to

*requiring* the Consume to analyze or even modify JavaScript.  Such a

statement would seem to need a positive assertion that such modification

*is* a requirement (something which again, I view as open).

Customization is definitely something that we will be discussing in the Customization sub-committee. My working assumption is that the requirement below is rather generic, and applies to anywhere from the scope of WSIA in general, to action routing, unique tokens, etc., and that it might be changed as the Customization sub-committee proceeds.

I guess my take is that it is too generic.  It seems to be trying to

take a half step and would result in muddying things instead of making

them clearer.  If it really doesn't place any restrictions one way or the

other on our work, then it doesn't seem like a requirement and I would

argue it should not be included.

Sean

Eilon

-----Original Message-----

From: Sean Fitts [mailto:sean@crossweave.com]

2. It MUST support JavaScript as an associated scripting language and MUST provide a way to support actions triggered by scripts. [Optional/Debate: However, it MUST NOT be assumed that scripting elements are modified by the Consumer in any way.]

Why do you feel that the second "MUST NOT"
statement is necessary? 
To me it seems overly restrictive since it impacts both what types of
customization we will support and where the customization will occur.
My understanding is that both of these issues are still up for debate/
description in the customization sub-group.

>