MHonArc v2.5.2 -->
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]
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.