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]

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.


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