RE: [wsia][wsia-requirements][R602]

[Rex Brooks <rexb@starbourne.com>]

Title: RE: [wsia][wsia-requirements][R602]

I also did not sign up for this debate, but I didn't sign up for any because I am not able to be responsible for carrying out the commitment. Until other decisions that are pending on contracts are decided, I didn't and don't want to volunteer, even though I have the time right now. While this may be true for everyone all the time, I just happen to have real irons in the fire right now.

As a Generic Graphic Designer, Flash gives me the kinds of options for interaction that I want, although for myself in particular I will attempt to switch over to SVG with several higher level scripting language options for handling the interaction to SVG output. However, the point is that Flash is fairly ubiquitous and we need to make some kind of accommodation to it.

I can see several kinds of options we might consider in practical terms, though I am not sure how to phrase these as requirements, nor if we should get that specific in a requirements documents--both extremes of exhaustive (and exhausting) detail and nearly total lack of specificity exist.

Regardless:

1: We could write and require a standard disclaimer for inclusion in the pages served up by Consumers to End Users of Flash and binaries, etc, saying something like "(Consumer-Provider) provides this (Service) on behalf of (Producer) without any capacity to alter it for our clients/subscribers/users."

2: We could  say that all output formats must be alterable or will simply not be covered as WSIA-compliant and let output vendors and Producers deal with it.

3: We could defer it to the next round and let the battle be fought elsewhere.

I favor Number 1, and specifically including HTML, XHTML, WML and XML.

Ciao,

Rex

At 1:06 AM -0400 5/6/02, Eilon Reshef wrote:

> I'll put my 1.5 cents into this discussion, even
> though I didn't originally put my name for it :-)
>  
> I think that it more than makes sense that we
> shouldn't ask the Consumer to parse and modify Flash content, Java
> applets, or any other binary format.
>  
> The question in my mind (regarding the actual intent
> of this requirement) is: should the WSIA protocol *permit* some
> sequence of calls in which a WSIA Web Service that contains
> Flash/Java/ActiveX with links or forms would still work, even
> though it has user interaction, and even though "smart
> look-and-feel customization" (whatever this is) will not be
> offered.
>  
> This point - although seemingly minor - may have
> significant implications on the actual protocol with regards to action
> routing.
>  
> If we do decide that binary formats should be
> supported even at a basic level, then (at least according to my
> possibly limited understanding) this means that we must provide at
> least some way (not necessarily the "mainstream" way) for
> the Consumer to provide enough information to the Producer (who serves
> the binary data) so that the binary content is served in such a way in
> which all the actions are routed correctly to the Consumer. This means
> that the Producer has to take care of it, but it would make it
> doable.
>  
> We at WebCollage have encountered some cases where
> people used Flash for parts of their applications, so it made sense
> for us to consider it. However, we need to decide whether this is
> something that the WSIA committee as a whole cares
> about. 
>  
> Eilon
> > -----Original Message-----
> > From: Alan Kropp [mailto:akropp@epicentric.com]
> > Sent: Friday, May 03, 2002 8:41 PM
> > To: 'wsia@lists.oasis-open.org'
> > Subject: [wsia][wsia-requirements][R602]
> > R602 [Flexibility]
> >        
> >         This
> > specification should support common Presentation
> > Formats, which are in use today in Net-enabled
> > applications. In particular,
> > it should support HTML, XHTML, WML and XML
> > as Presentation Formats. It must
> > not preclude the use of other presentation formats
> > (Eilon: such as Flash,
> > GIFs, etc.). Debate on last sentence: AK,
> > CW.
> > I think only XML and HTML (due to its
> > ubiquity) markups should be supported
> > by name, other formats should be
> > considered opaque in the markup stream.
> > Last sentence should read:  
> >  It must not preclude the use of
> > other presentation formats, although these
> > (e.g., Flash, GIFs, etc.) shall be considered opaque
> > in the markup stream.
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the
> > subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>

--