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
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...
This specification must support common Presentation formats, which are in use today in Net-enabled applications. In particular:
1. IMUST support Presentation Fragments in HTML, XHTML, XML and WML.
2. It MUST support ECMAScript as an associated scripting language, and MUST include a way to correctly route Actions triggered 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.
 -----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