OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: RE: [wsrp][markup] Second conference call

Title: Message
A few questions:
1. Is there any particular reason to disallow style and link tags? It would seem to me that as long as the portlet ensures that the styles used are unique (which can be easily done in different ways, one being CSS scoping), there shouldn't be an issue with that. Is that true?
2. In general, I think it would be preferable to use the term "discouraged" rather than "disallowed" when referring to the markup. The semantics of some tags (e.g., <base>, <meta>) may be relevant in some cases, assuming the portlet knows what it's doing. It is naturally the portlet's responsbility to behave "nicely" in a larger page.
3. As for URL rewriting, wouldn't it be beneficial to define as part of the protocol a way for the portal to transfer the action-routing URL to the portlet so that it can write the URL correctly in the first place if it wishes to? After all, there's a good chance that the logic will be there anyway if the developer wants to debug the portlet outside the context of a particular portal (in which case the URLs need to be "straightened out :-)" as they are written, namely: no unique prefixes).
-----Original Message-----
From: David Taieb/Cambridge/IBM [mailto:david_taieb@us.ibm.com]
Sent: Monday, April 22, 2002 3:51 PM
To: Gino Filicetti
Cc: 'wsrp@lists.oasis-open.org'
Subject: Re: [wsrp][markup] Second conference call

Here's a draft document that outlines the differents issues raised at our
first conference call and tries to capture the email discussions that

(See attached file: WSRP Markup.html)(See attached file: WSRP Markup.DOC)

|         |           Gino Filicetti   |
|         |           <gfilicetti@bowst|
|         |           reet.com>        |
|         |                            |
|         |           04/18/2002 06:33 |
|         |           PM               |
|         |                            |

  |                                                                                                                              |

  |       To:       "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>                                                    |

  |       cc:       (bcc: David Taieb/Cambridge/IBM)                                                                             |

  |       Subject:  [wsrp][markup] Second conference call                                                                        |



The time has come for our 2nd conference call.... I didn't bother
it this week because of the clash with the WSIA F2F... Here is the

Date: Tuesday, April 23, 2002
Time: 12:00 PM Eastern, 9:00 AM Pacific
Duration: 1 Hour

 To join this conference:

For quick access, go to https://bowstreet.spiderphone.com/27914907
(This link will help connect both your browser and telephone to the call)

OR dial 1 (866) 633-2978 or +1 (646) 485-9300 and enter 2791 4907


Here is a list of issues that we've been grappling with over email since
last conference call; I'd like to discuss each one, and see where that
us. It's a pretty long and exhaustive list and it's fully expected that we
may not be able to hit each one during this call.....

- Should we standardize on XHTML? Do we want to discourage the use of old
style HTML but still accept it? Or refuse non-parsable HTML out-right?

- Acceptable tags in (X)HTML
  - should we specify a list of ALLOWED or DISALLOWED tags?
  - are there some tags that aren't exactly DISALLOWED but rather
  - go over the currently proposed list of disallowed tags in (X)HTML
    - base, body, frame, frameset, head, html, link, meta, style, title

- Should a portlet be aware of its surroundings?
  - does the portal have to tell the portlet what it's surrounding tag will

- Do we want to tackle VoiceML and WML now?

- How do we deal with signed java applets, images and other resources that
the aggregator is going to have to proxy?

- Carsten proposed that portlets could send their markup in 3 sections,
begin page, main markup fragment and end page. This would allow a portlet
insert markup into other places in the final page that the aggregator
  - Sasha believes we should either make the possible locations that a
portlet can insert markup into extensible (ie: not hardwired to 3), or just
restrict it to one location.

- how will portlets define and use javascript methods?
- how will we encode javascript elements?
- will there be shared methods?

URL Rewriting
- Three suggestions on the table (first 2 from Carsten, third from Sasha)

1. Aggregator sends a prefix w/ request and portlet must use it to do the
URL boundary demarcation. The aggregator then parses the markup looking for
the prefix it provided.

2. All portlets use a predefined prefix which is part of the spec to
demarcate URL boundaries. The aggregator then parses the markup looking for
the well known prefix.

3. The aggregator automatically parses markup and heuristically determines
URL boundaries and does the necessary rewriting automatically.

- Is a prefix good enough to demarcate a URL? Do we need a more robust
  - Sasha suggests taking advantage of XML namespaces, and using regular
tags to demarcate a URL.

Namespace Encoding
- the mechanism used to encode namespaces should be the same the used in
- what types of things need to be encoded?
  - form and input names
  - javascript variables
- How does this impact the portlet writer and their pre-existing

Visual Styles
- only very preliminary discussion has been done.
- lists of possible styles have been submitted by Thomas (used in WSP) and
Alan (used in WSUI): see attached file.

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