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

[Rex Brooks <rexb@starbourne.com>]

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

Um, okay, I guess. I'm marginally happier with ECMAScript.

It doesn't make sense to fuss over it, but if a browser can display it and an end user can interact with it, propagating an action back up the chain, we have to deal with it. Even just saying that it isn't popular enough for consideration is dealing with it. Staying with Client Side in this requirement is okay with me. Is that a general consensus?

Regardless, the point I was making was not really about languages that some of my clients and associates insist on using, which requires me to use them the same way that the ubiquity of Wintel programs requires me to use them. The point was using the "MUST NOT preclude..." construction. I shoulda left it at that, but the question illustrated the "What about this, that and the other thing..." generic reaction to "enabling" something without specifically mentioning every marginally popular language or protocol as well.

Harmonizing with W3C seems like a good idea, too.

Ciao,

Rex

At 3:28 PM -0700 5/8/02, Sean Fitts wrote:

> This requirement opens with the phrase
> (emphasis mine):
>
> "This specification must support
> common *Presentation* formats..."
>
> To me that means that this requirement is specifically
> addressing
> what will be emitted for eventual consumption by an end client
> (for
> instance the browser).
>
> I don't think we want to confuse the issue by also bringing server
> side scripting languages into the mix (they may need to be
> addressed
> as part of another requirement, but I'd prefer to keep this one
> focused
> on the delivery side).
>
> That said, Brian's original question is an interesting one.  I
> don't know
> of other, client side scripting languages that are widely supported
> in
> the market.  I know that IE supports Visual Basic as a client
> side
> scripting language and will presumably support C# as part of its
> ..NET
> initiative.  However, I think that we should stick to
> standardized
> technologies.
>
> Perhaps it would be better to change JavaScript to ECMAScript
> (which
> is I believe how the W3C refers to it).
>
> Sean
>
>
>
>
> 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.
> >
> > Ciao,
> > Rex
> >
> > 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
> > > brian.r.young@boeing.com
> > > 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.
> > > >
> > > >
> > > > 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.
> > > > >  
> >
> > --

--