WSIA 5/8/2002: [wsia][wsia-requirements][R602]

[Monica Martin <mmartin@certivo.net>]

One thing that this lengthy and varied discussion has clearly shown,
that we may never be able to define a comprehensive set of client-side
scripting languages unless for an instant (Sorry, everyone I am not a
programmer by choice).  Perhaps we should concentrate on what this
requirement is trying to accomplish:

*	Provide a mechanism to support triggered actions
*	Provide support for Presentation Fragments
*	Provide support for embedded Presentation Fragments

As for the modifications and/or adaptions that were discussed, this
detail may be better left to subcommittee tug-of-war.  Suggest we
concentrate on the what, before the how.
 
Thanks.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946
 
 
-----Original Message----- 
From: Eilon Reshef 
Sent: Wed 5/8/2002 3:38 PM 
To: 'Sean Fitts'; wsia@lists.oasis-open.org 
Cc: 
Subject: RE: [wsia][wsia-requirements][R602]



	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.