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]



I would note that we should keep the list of languages as short as
possible. The general case is support for XML & HTML. XHTML & WML are
included only due to their prevalence in the marketplace. SVG (& many other
interesting/useful languages) is covered by supporting XML.


                                                                                                                
                      Kurt Cagle                                                                                
                      <kurt@kurtcagle.n        To:       wsia@lists.oasis-open.org                              
                      et>                      cc:                                                              
                                               Subject:  Re: WSIA 5/9/2002: [wsia][wsia-requirements][R602]     
                      05/10/2002 01:30                                                                          
                      PM                                                                                        
                                                                                                                
                                                                                                                



I'm a general lurker on this list, so I apologize if I'm out of line here.
I'd make a strong recommendation that in your formal MUST support
requirements that you include SVG in that list as well. It is, as of
January, unencumbered and Open Source, it is an XML format that's supported
by both Windows and Linux based browsers, and it provides the one piece of
infrastructure that XHTML, WML, etc. don't give you - precise graphics
creation - I'm already building a framework around it to replace some of
the
more graphical elements of HTML (tabs, button bars, buttons, gauges, etc.)
and my early experimentation with it has worked great.

On the other front, concerning plug-in technology, I'd recommend just
taking
a hint from HTML and create a standardized <object> or <embed> capability
that includes parameter passing, plug-in source code and viewport
specification sizes. Couple this with a mechanism to let these plug-ins
hook
into a native web service capability for conformity sake, and you don't
need
to worry about formal support of a given vendor's products - they would
instead write a wrapper AI to be conformant with the WSIA spec.

-- Kurt Cagle




----- Original Message -----
From: "Rex Brooks" <rexb@starbourne.com>
To: "Sean Fitts" <sean@crossweave.com>; "Ravi Konuru" <rkonuru@us.ibm.com>
Cc: <wsia@lists.oasis-open.org>
Sent: Friday, May 10, 2002 10:11 AM
Subject: RE: WSIA 5/9/2002: [wsia][wsia-requirements][R602]


> 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 <eilon.reshef@webcollage.com>, "'Monica Martin'"
> >>                       com>
> >><mmartin@certivo.net>, wsia@lists.oasis-open.org
> >>                                                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: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
> >>                     >
> >>                     >                                 -----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
> >>             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>
>
>
> --
>
> ----------------------------------------------------------------
> 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>







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC