I think it is valuable to gather a list
of the various presentation languages available today. This list should
then be prioritized based on current and expected near-term usage. Perhaps
generating the list (with some usage statistics) should be the focus until
the F2F and the prioritization be placed on the F2F agenda.
I disagree that ASP and JSP belong on
the list. They are technologies for generating markup rather than markup
languages that are transmitted. I'm sure the Coordination subgroup will
consider the ramifications of popular technologies when it discusses/designs
the "eventing" model. If there are specific issues, they should
be contained to that discussion rather than spread across several subgroups.
Rich Thompson
Rex Brooks <>
04/16/2003 03:34 PM
To:
cc:
Subject:
[wsrp] Fwd: [wsrp-markup] Re: [wsrp-wsia]
wsrp-markup meeting notes, charter, preliminary f2f agenda items
I forgot to copy this to the list when I replied.
Ciao,
Rex
Date: Wed, 16 Apr 2003 12:09:56 -0700
To: "Thomas Schaeck" <>
From: Rex Brooks <>
Subject: [wsrp-markup] Re: [wsrp-wsia] wsrp-markup meeting notes, charter,
preliminary f2f agenda items
Cc:
Bcc:
X-Attachments:
Hi Thomas,
I expect the list to grow, but how much remains to be
seen. I thought it would be better to start with specifics. SMIL is Simultaneous
Mutlimedia Integration Language
http://www.w3.org/TR/REC-smil/
http://www.w3.org/AudioVideo/
SVG is Scalable Vector Graphics
http://www.w3.org/TR/SVG/
VRML isthe ISO 3D standard and is being updated to X3D,
a modularized, xml-based version. I believe it is ready for ISO now
http://web3d.org/
The particulars of how each of these presentation languages
are somewhat distinct is beyond the scope of a quick discussion, but they
are all scriptable, which makes them candidates for use with interactive
portals customized to individual preferences. Markup Fragments and the
rules that pertain to them are also a bit beyond a quick discussion.
ASPs, JSPs, etc require consideration because they are
scripts and the whole issue of eventing is still ahead. Certainly not for
1.1, but certainly for 2.0.
I agree on the sentence change. I suspect that is just
the tip of the iceberg here.
I also agree on taking a poll on what markup languages
are needed for 1.1. Most of what I have included in the charter is really
aimed at 2.0.
I also agree that WAP Fragment Rules and Markup Fragment
Rules in general are important for 1.1.
Ciao,
Rex
Hi Rex,
thanks for sending the draft of the charter !
I have some questions / remarks:
It is very good that you listed the concrete sections of the spec that
you
expect to be affected. Is this list comprehensive or do you expect it to
grow ?
What are SMIL and SVG ? Which devices / browsers support them as a markup
languages for presentation ?
I think VRML is for 3D graphics ? If yes, I am not sure how it would be
practical to define markup fragments for this. I would rather have expected
that you might have something like an HTML markup fragment with a link
to a
VRML document being produced by the WSRP service and then when displayed
in
the end user's browser and the user clicks on the link, the browser would
load the VRML plugin to display the VRML file. In that case I would expect
that no WSRP markup fragment definition for VRML would be required, WSRP
would just be agnostic of what documents are linked to from the markup
fragments.
I am not sure why ASPs, JSPs and PHP are listed - since they are mechanisms
to generate markup on the server side, I'd assume the WSRP standard should
remain agnostic of these specific ways to implement WSRP services.
You might want to change the sentence "* Section 10 Markup: Markup
Fragment
Rules for various implementations" to "* Section 10 Markup: Markup
Fragment
Rules for various markup languages"
Maybe we could initiate a vote on the web site to have the TC express what
markup languages they are most interested in for the 1.1 time frame and
what people think could be done in the 2.0 timeframe. Richard, is it
possible to set up a vote like that somehow ?
Personally, I think an important thing we should look at for WSRP 1.1 are
markup fragment definitons for WAP phones (i.e. WML / XHTML basic for
phones) and Voice phones (i.e. VoiceXML).
Best regards,
Thomas
|---------+---------------------------->
| | Rex
Brooks |
| | <rexb@starbourne.|
| | com>
|
| |
|
| | 04/16/2003
07:30 |
| | PM
|
| |
|
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: ,
, ,
|
|
|
| cc:
|
| Subject: [wsrp-wsia] wsrp-markup meeting
notes, charter, preliminary f2f agenda items
|
|
|
>------------------------------------------------------------------------------------------------------------------------------|
Hi Everyone,
Please excuse the multiple postings, but I wanted to make sure that anyone
interested in the wsrp-markup subcommittee sees this post.
We did have a telecon meeting today, even though there were only three
participants on the call. Since there was not adequate advance notice,
I
won't treat it as a regularly scheduled meeting. So I won't post minutes,
nor record attendance this time. However we did decide that due to schedule
a regular meeting week after next, Wednesday, April 30, 2003 at
8 am PST / 11 am EST / 5 pm CET, 1 hour
US dial in #: 1.888.481.3032
International Dial in #: 1.617.801.9600
Participant Passcode: 28614774 (you will be asked for your name)
UK 0800 904 7961
D 0800 1813856
I have also added it to the sc calendar, so the call-in information can
be
found there as well.
The agenda for that meeting is:
Finalize and Vote on Charter.
Finalize recommendations for Face to Face Agenda Items from this
subcommittee.
Here is the charter as it exists so far:
Charter
The purpose of the WSRP Markup Subcommittee is to
1. Identify and recommend best practices for WSRP Specification 1.0 for
* Section 4.2 Markup Operations: MarkupResponse, MarkupParams;
* Section 5.1.10 MarkupType Types;
* Section 6 Markup Interface: MarkupParams Type, MarkupContext
Type,
MarkupResponse Type;
* Section 6.2 getMarkup() Operation: caching
of markup fragments,
Cachability, Cache Invalidation; and
* Section 10 Markup: Markup Fragment Rules
for various
implementations
2. Identify markup specifications and proprietary formats for consideration
in moving forward from for WSRP Specification 1.0, including but not
restricted to
* XHTML (HTML, XHTML Basic, CSS)
* VoiceXML,
* WAP,
* SMIL,
* SVG,
* Application-specific MIME Types such as Flash,
* standard MIME Types for special interests,
such VRML and
* emerging specifications of interest, such as i-
mode,
* scripting languages and the namespacing of such languages/practices as
Javascript, ASP. JSP, PHP, CSS
3. Develop Recommendations for Defining Templates for all such Markup
Types, MIME Types, Markup Fragments, amd Best Practices for such
4. Identify and recommend liaisons with other standards organizations and
working groups to coordinate efforts, harmonize specifications, and ensure
as much as possible the ease of interoperability of these standards and
practices.
Name
The name of this subcommittee shall be the OASIS WSRP Markup Subcommittee.
Mailing-List
Deliverables
The deliverables of this subcommittee will be:
Publish Reports fulfilling the numbered items of our listed purposes.
Preliminary agenda items for f2f:
* Section 6.2 getMarkup() Operation: caching of markup fragments,
Cachability, and Cache Invalidation;
* Section 10 Markup: Markup Fragment Rules for various implementations
* templates and scripting considerations, including the addition of
specification information such as javascript in headers, including issues
of "look and feel" for standard common features such as buttons,
and
including user interface description language options.
It should be noted that we have only identified specific areas from the
existing charter that pertain to issues we think should
be discussed in
regard to whether we need to address them immediately in a 1.1 version
and/or need to be addressed in the next version whether it be 1.x or 2.0.
This is an admittedly superficial gloss of issues that need to be fleshed
out in our next meeting.
Ciao,
Rex
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
Tel: 510-849-2309
Fax: By Request
>
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
Tel: 510-849-2309
Fax: By Request
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email:
Tel: 510-849-2309
Fax: By Request
