[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]
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. It MUST 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]
- 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
- >