[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
Here's another round based on the latest comments, with a clearer distinction between what we commit to do versus what we wish to do long term (based on Ravi's observation). I also don't think we need to spell out the different things that are supported, but I do see an slight conceptual distinction between action routing and customization (see below).
This specification must support common Presentation formats, which are in use today in Net-enabled applications. In particular:
Ravi, thanks. Your description of providing "support" for a format vs.
just passing it along (and making sure not to muck it up) is exactly
what was lurking in the back of my mind.I guess the thing that confused me was that we explicitly called out
Action routing, but failed to mention all the other aspects of providing
"support" for a given element. I wasn't sure if this was intentional or
just because the other aspects are handled by other requirements.For instance, if the WSIA supported Action routing from scripts, but
did not support adaptation of generated markup, would it meet this
requirement? I don't think it should, but I'm not entirely sure that this
is true as currently worded.So, 2 questions - do others agree that we need to provide "complete
support" (as outlined by Ravi below) for scripts? If not, why not?Any thoughts on the current wording and whether it captures this intent?
Sean
At 09:04 AM 5/10/2002 -0400, Ravi Konuru wrote:
> > 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>
----------------------------------------------------------------
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