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 5/9/2002: [wsia][wsia-requirements][R602]


Title: Message
How about breaking this into two separate requirement that represent 1-3 and 4?
 
I would be slightly concerned with a requirement that hints that we should put up guidelines or restrictions for developers. In fact, I believe that the business requirement should be "do not restrict the way people do things in any way". If us, as a technical committee, cannot answer that business requirement, that's fine (we won't be able to answer all), but it's better to clearly put a stake in the ground as to what we are trying to achieve, and then discuss on priorities. Same goes with not fully supporting Flash/Applets/etc. - they should be supported. (I did not fully understand your suggestion below, so I might still be missing something.) If we (or: a particular technical approach) can't manage to, that's our fault, but that doesn't mean that the requirement is not there... I believe that otherwise, we run into a risk that the spec will eventually be dominated by clean technical ideas, but will end up not meeting the real business requirements.
 
Eilon
 
-----Original Message-----
From: Ravi Konuru [mailto:rkonuru@us.ibm.com]
Sent: Friday, May 10, 2002 3:16 PM
To: Eilon Reshef
Cc: 'Sean Fitts'; wsia@lists.oasis-open.org; Kurt Cagle
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]


Eilon, this is really nice, thanks for continually trying to rationalize
this particular requirement. I think it is a particularly important one.

The first three are clear. My opinion is that reqt 4 is not at the same
granularity as the other three reqmts. I would divide 4 into the following.

      4a. It MUST define guidelines on Presentation Fragments in HTML,
XHTML, XML and WML so that features mentioned elsewhere in the document
such as  action routing and adaptation can be performed.
      4b. It MUST?SHOULD define guidelines on  ECMAScript scripts so that
features such as action routing and adaptation are enabled.
      4->4c Functionality offered elsewhere in this specification (e.g.,
action routing, customization) SHOULD NOT be restricted based on a
particular presentation format. However, this specification MAY only
provide constructive guidelines for other restricted set of presentation
formats

Also, we should think of this extracted response from Kurt Cagle's mail in
the context of 4c. I think its very relavant. In fact, this was also one of
the thoughts in IBM's WSXL position paper. We may want to use this line for
all binary formats. Imagine
if script writers follow this approach :-) then we are all set. We don't
have to grok through anything anymore.

On the other front, concerning plug-in technology, I'd recommend just
taking
a hint from HTML and create a standardized <object> or <embed> capability
that includes parameter passing, plug-in source code and viewport
specification sizes. Couple this with a mechanism to let these plug-ins
hook
into a native web service capability for conformity sake, and you don't
need
to worry about formal support of a given vendor's products - they would
instead write a wrapper AI to be conformant with the WSIA spec.




Ravi Konuru
eBusiness Tools and Frameworks, IBM Research
office: 914-784-7180, tieline 8-863-7180; fax -3804


                                                                                                                           

                      Eilon Reshef                                                                                         

                      <eilon.reshef@webc        To:       "'Sean Fitts'" <sean@crossweave.com>, Ravi                       

                      ollage.com>                Konuru/Watson/IBM@IBMUS                                                   

                                                cc:       wsia@lists.oasis-open.org                                        

                      05/10/2002 01:44          Subject:  RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]               

                      PM                                                                                                   

                                                                                                                           

                                                                                                                           



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:


1. It MUST support Presentation Fragments in HTML, XHTML, XML and WML.

2. It MUST support Presentation Fragments and Actions created by ECMAScript
scripts.

[ER]: Presentation Fragments are document.write() and DOM function calls.
Actions are navigation (non-presentation) function calls (such as
location.replace).

3. It MUST support embedded elements (e.g., Images, Flash, Applets, etc.)
(and Actions created by such elements?).

[ER]: Presentation Fragments are things displayed to the user, actions are
navigation commands. I do think that not allowing supporting actions in
such formats is limiting.

4. Functionality offered elsewhere in this specification (e.g., action
routing, customization) SHOULD NOT be restricted based on a particular
presentation format. However, this specification MAY only provide
constructive guidelines for a restricted set of presentation formats.

-----Original Message-----
From: Sean Fitts [mailto:sean@crossweave.com]
Sent: Friday, May 10, 2002 12:28 PM
To: Ravi Konuru
Cc: wsia@lists.oasis-open.org
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]




      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