[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
Sean,
> cHTML
Unless there is a requester or we have a convincing reason lets not
consider it. I don't have one.
> Do we want to say anything about additional Presentation Fragments
generated
> by scripts?
We MUST support them and I am assuming that by support, we mean action
routing, interpretation, and adaptation. As you pointed there is so much
use of it that we cannot ignore. However, in general wrt javascript do we
explicitly mention that there may be guidelines on javascript coding so
that we can do routing?
After reading through your version of reqmt 3. It seems we need to
distinguish between delivering a format opaquely/pass-through vs what I
defined above as support. Should we use the words "Carry or Opaquely
transport" and "Support" to distinguish the two or am I missing something?
regards,
Ravi Konuru
eBusiness Tools and Frameworks, IBM Research
office: 914-784-7180, tieline 8-863-7180; fax -3804
Sean Fitts
<sean@crossweave. To: Eilon Reshef <eilon.reshef@webcollage.com>, "'Monica Martin'"
com> <mmartin@certivo.net>, wsia@lists.oasis-open.org
cc:
05/10/2002 03:05 Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
AM
At 10:11 PM 5/9/2002 -0400, Eilon Reshef wrote:
If I remember correctly, Sean did not feel comfortable with the last
sentence of statement 2 and the word "binary".
So, where we stand might be the following, with the exception that we
still need to solicit input on the second part of statement 3.
Sean - I did no go back to the somewhat long discussion yesterday, so
please do (continue to ;-) correct me if I missed something...
No problem, sorry for rambling on, it's really not like me :-).
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.
Do we want to include cHTML or is that dead at this point?
2. It MUST support ECMAScript as an associated scripting language,
and MUST include a way to correctly route Actions triggered by
scripts.
Do we want to say anything about additional Presentation Fragments
generated
by scripts?
3. It SHOULD support other embedded elements (e.g., Flash, Applets,
etc.), and SHOULD provide a way to correctly route Actions triggered
by such elements.
Personally, I would prefer to leave action routing from such elements for a
later
version of the specification. I haven't seen any comments from others on
this
(though they may have been lost in the recent exchange :-).
My proposal would be:
3. It MUST support other embedded elements (e.g., Flash, Applets, etc.),
but
need not provide a way to correctly route Actions triggered by such
elements.
Sean
-----Original Message-----
From: Monica Martin [mailto:mmartin@certivo.net]
Sent: Thursday, May 09, 2002 7:13 PM
To: Sean Fitts; Eilon Reshef; wsia@lists.oasis-open.org
Subject: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
Agreed.
Eilon, are we close?
Thanks.
Monica J. Martin
Program Manager
Drake Certivo, Inc.
208.585.5946
-----Original Message-----
From: Sean Fitts
Sent: Wed 5/8/2002 10:44 PM
To: Monica Martin; Eilon Reshef;
wsia@lists.oasis-open.org
Cc: Monica Martin
Subject: Re: WSIA 5/8/2002:
[wsia][wsia-requirements][R602]
This make sense. My main goal was to point out that
the
"presentation
fragments" referred to below consist only of "markup".
They
don't today
and they won't in the future. I think we all agree
that some of
the
non-markup
bits will be opaque (what we have been calling
"binary"), but
that others
will not be.
I do think that it is useful to map these concepts into
the
specific set of
technologies in use today (even if that mapping is
temporary).
It helps serve
as a sanity check that what we do will be relevant to
web
application
developers
(not to mention the fact that I think better with
concrete
examples :-) ).
In terms of the goals you outline below, I would add:
* Provide a mechanism to support modification of
Presentation
Fragments based on Consumer supplied criteria.
Note that this leaves aside the issue of where such
modifications are
performed.
Sean
At 08:18 PM 5/8/2002 -0700, Monica Martin wrote:
>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.
>
>
>
>
>
>
>
>
>
----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the
subscription
>manager: < http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC