Complete support sounds like a plan to me, too.
Ciao,
Rex
At 9:27 AM -0700 5/10/02, Sean Fitts wrote:
>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 <>, "'Monica Martin'"
>> com>
>><>,
>> 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:]
>> Sent: Thursday, May 09, 2002 7:13 PM
>> To: Sean Fitts; Eilon Reshef;
>> 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;
>>
>> 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';
>> >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:]
>> > Sent: Wednesday, May 08, 2002 5:57 PM
>> > To: Eilon Reshef;
>>
>> > 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:]
>> > Sent: Wednesday, May
>> 08, 2002
>> 2:14 PM
>> > To: Eilon Reshef;
>> 'Rich
>> Thompson';
>> >
>> > 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:]
>> >
>> >
>> > 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>
--
