OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

At 3:32 PM -0700 5/8/02, Sean Fitts wrote:
Beyond the client side/server side issue here, I'd take issue with the
statement that "in that first paragraph so that stipulating Javascript
is understood as standing on par with binaries as obvious?".

In my mind JavaScript is not on par with binary elements and should
not be treated the same way.  This is the whole reason for calling it
out and saying that it will be modifiable.

Uh, all we are saying is that it SHOULD NOT be assumed that the Consumer will modify binaries, not that Consumer won't be allowed to modify them. So, I thought that it was just about equal in that sense, and had the same standing, however, you convinced me otherwise. By and large I expect Consumers will do their best to modify as little as necessary in both, although adding features such as comparisons with the same data over time by pulling up older information from other sources is just the kind of feature I could see as being helpful added service.

The script that is part of a presentation format needs to be just as
customizable as the markup itself.


At 03:07 PM 5/8/2002 -0700, Rex Brooks wrote:
I have the same concern, but I am assuming that the first paragraph covers such languages as Perl for CGI and Python, but while we are at it, should we consider adding an e.g. in that first paragraph so that stipulating Javascript is understood as standing on par with binaries as obvious? And since we are already specifying CSS and fragments, I have a personal interest in seeing support PHP as well ASP and JSP. This is exactly what I meant by saying that I prefer using the MUST NOT preclude phrasing, for now, and establishing a sample implementation and reference implementations from which to conduct conformance testing by rev 2... or 3.


At 2:53 PM -0700 5/8/02, Young, Brian R wrote:
What about support for scripting languages other than JavaScript?
Brian R. Young
The Boeing Company
(425) 865-5834
DISCLAIMER: Any opinions expressed in this e-mail are my own and do not necessarily reflect the position of my company.

-----Original Message-----
 From: Eilon Reshef [mailto:eilon.reshef@webcollage.com]
 Sent: Wednesday, May 08, 2002 1:51 PM
 To: 'Sean Fitts'; wsia@lists.oasis-open.org
 Subject: RE: [wsia][wsia-requirements][R602]

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):

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.


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.
 -----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.



 -----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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC