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: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
I will just add my comments where they occur. I am assuming that no one has a problem with this reply method. I don't, but some groups I in which I have participated have asked for entire replies separately either before or after the post to which they are responding. I prefer this, but I know it bothers some people.

At 12:05 AM -0700 5/10/02, Sean Fitts wrote:
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?

I don't.
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?

I don't

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 :-).

Since we have crafted a clear distinction between Actions and Events and we will be stipulating the use of "Handles" and specific methods of URL rewriting, I think we definitely do want to insist on correct routing of Actions.

Q1: Does this constitute an added burden on the embedded elements that we want to avoid?

Q2: Is it possible for such an Action to be inadvertently misrouted?

Q3: If A to Q2 is yes, can we provide a quick and low-overhead validation method to throw an exception if misrouting occurs?

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.


 -----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]

 Eilon, are we close?
 Monica J. Martin
 Program Manager
 Drake Certivo, Inc.

        -----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

         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

         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

         (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

                  Fragments based on Consumer supplied criteria.
         Note that this leaves aside the issue of where such
 modifications are

         At 08:18 PM 5/8/2002 -0700, Monica Martin wrote:
         >One thing that this lengthy and varied discussion has clearly

         >that we may never be able to define a comprehensive set of

         >scripting languages unless for an instant (Sorry, everyone I am
 not a

         >programmer by choice).  Perhaps we should concentrate on what

         >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,

         >detail may be better left to subcommittee tug-of-war.  Suggest

         >concentrate on the what, before the how.
         >Monica J. Martin
         >Program Manager
         >Drake Certivo, Inc.
         >-----Original Message-----
         >From: Eilon Reshef
         >Sent: Wed 5/8/2002 3:38 PM
         >To: 'Sean Fitts'; wsia@lists.oasis-open.org
         >Subject: RE: [wsia][wsia-requirements][R602]
         >         My thought was around people that use scripts like

         >         <script>
         >         var target = " http://" + gMyDomain +
 "/mypage.rgb?page=" +

         >         document.location = targert;
         >         </script>
         >         My intent was to formulate a part of the requirement

         >clearly states that WSIA cannot expect Consumers to

         >rewrite this action to point back to the Consumer.
         >         Does this make sense as the intent of this part of the
         >         As for a proposed solution, one can consider three

         >         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

         >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

         >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

         >                         I think I see your point (I thought of
         >modification as semantic versus syntactic), how about the

         >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
         >externally (ala the adaptation
         >                 description in WSXL).
         >                 I guess I don't see a lot of difference here

         >this type of modification and
         >                 general markup modification.  Both contain

         >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

         >scripting language. Such support MUST include a way to support

         >triggered by scripts. However, it SHOULD NOT be assumed that

         >Consumer is aware of the semantics of scripting elements.
         >                 Given the parallel between semantics of

         >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

         >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

         >don't see it as a high-level requirement but rather as a

         >                 Could you elaborate on this?  I'm not sure I

         >                 Sean
         >                                 -----Original Message-----
         >                                 From: Sean Fitts [
         > mailto:sean@crossweave.com]
         >                                 Sent: Wednesday, May 08, 2002
 2:14 PM

         >                                 To: Eilon Reshef; 'Rich

         >                                 Subject: RE:
         >                                 At 01:55 PM 5/8/2002 -0400,
 Eilon Reshef

         >                                 I am not suggesting that the
 Consumer is

         >not allowed to change JavaScript, rather the suggestion is that

         >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

         >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
         >Adaptation Description Language
         >                                 proposed by IBM to include

         >modifications along with XML
         >                                 and CSS ones.
         >                                 This is not to say that WSIA

         >define an interface that uses JavaScript (e.g., I assume the

         >may decide to define JavaScript functions, events, etc.), but I

         >that the question is can we require the Consumer to analyze

         >code to support action routing, for example?
         >                                 Again, I don't see how leaving

         >second sentence out leads to
         >                                 *requiring* the Consume to
 analyze or

         >even modify JavaScript.  Such a
         >                                 statement would seem to need a

         >assertion that such modification
         >                                 *is* a requirement (something

         >again, I view as open).
         >                                 Customization is definitely

         >that we will be discussing in the Customization sub-committee.

         >working assumption is that the requirement below is rather
 generic, and

         >applies to anywhere from the scope of WSIA in general, to

         >routing, unique tokens, etc., and that it might be changed as

         >Customization sub-committee proceeds.
         >                                 I guess my take is that it is

         >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

         >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

         >                                 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

         >triggered by scripts. [Optional/Debate: However, it MUST NOT be

         >that scripting elements are modified by the Consumer in any

         >                 Why do you feel that the second "MUST NOT"
 statement is

         >                 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

         >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