Re: [wsrp][markup] Minutes for 5/8/02 conference call

[Khurram_Mahmood@peoplesoft.com]

Hi Folks,

Just a little question:  I was loooking at the list of disallowed and
discouraged tags and I couldn't find IFRAME (in-line frame) tag in the two
lists.  Allowing IFrame has a lot of the same disadvantages as smple
frames.  Why is that alowed?  Note that portlets can submit form with their
own iframes as targets.  Also just like freames, iframes have their own
history (in most browsers).  Except for the positioning problem that
regular frames have, all other disadvantages of using frames are shared by
iframes too.

Thanks,

KM

Khurram Mahmood


                                                                                                                                       
                      "Gino Filicetti"                                                                                                 
                      <gfilicetti@bowst        To:       "WSRP Mailing List (E-mail)" <wsrp@lists.oasis-open.org>                      
                      reet.com>                cc:                                                                                     
                                               Subject:  [wsrp][markup] Minutes for 5/8/02 conference call                             
                      05/08/2002 01:41                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       





Folks,

Please find attached the minutes for the latest conference call of the
Markup subcommittee. The agenda we followed appears below.

David Taieb will be updating our master document to capture the progress
that was made in today's call and will be sending that out for review in
the
next few days.

             Gino


> PROPOSED AGENDA
> ~~~~~~~~~~~~~~~
>
> Markup Tags
> ~~~~~~~~~~~
> - The list of DISALLOWED and DISCOURAGED tags for HTML and
> XHTML Basic are
> as follows:
> HTML:
>   Disallowed: base, body, frame, frameset, head, html, title
>   Discouraged: link, meta, style
>
> XHTML Basic:
>   Disallowed: base, body, head, html, title
>   Discouraged: link, meta
>
> - Question: What does it mean for a tag to be DISALLOWED?
> Does the inclusion
> of a disallowed tag invalidate the whole markup fragment?
>
>
> Style sheets
> ~~~~~~~~~~~~
> - This is the full list of styles submitted by Alan Kropp
> (WSUI) and Thomas
> Schaeck
> (WSP) organized into groupings:
>
> Fonts:
> wsui-font
> wsui-font-small
> wsui-font-large
> wsui-dim
> wsui-dim-small
> wsui-error
> wsui-error-small
> wsui-ok
> wsui-ok-small
> wsui-form-label
> portletText
> portletSmText
> portletTinyText
> buttonText
> fieldErrorText
>
> Tables:
> wsui-table
> wsui-table-row-header
> wsui-table-row-sectionheader
> wsui-table-row-odd
> wsui-table-row-even
> tableHead
> tableText
> tableShdRow
>
> Sections:
> wsui-section-title
> wsui-trail
> wsui-trail-current
> portletTitle
> portletTitleCust
> portletHead
> portletBody
> portletBack
>
> General:
> wsui-page-title
> wsui-block-bgcolor
> portletColorBack
>
> Menus:
> wsui-menu
> wsui-menu-current
>
> - we need to come up with a naming convention, and rename all styles
> - we need to trim the list and delete duplicates
> - Question: Should the spec provide a default set of values
> for the styles,
> or just
> the names and a description of the styles themselves?
>
>
> Secure Resources
> ~~~~~~~~~~~~~~~~
> - How do we deal with signed java applets, images and other
> resources that
> the client may not have access to?
>
> Two approaches envisioned...
> 1. The aggregrator proxies the request from the client to the
> remote portlet
> and proxies back the resource to the client.
> 2. The aggregrator caches the resource from the remote
> portlet and serves it
> to the client.
>
> - We need to come up with pros and cons of each approach.
> - Also open to any other approaches that people may come up with.
>
>
> URL Rewriting and Namespace Encoding
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> - go over the following 3 scenarios, and come up with a list
> of pros and
> cons
>
> Scenarios:
> 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.
>
> - Question: Will namespace encoding use the same method as
> URL encoding? Are
> there any specific differences between the two?
> - Question: Should we mandate the elements that should be
> namespace encoded
> or leave it up to the portlet developers to decide? Problem:
> If we mandate
> the elements, then the spec will need to be constantly
> updated to support
> new technology and we would have to explicitly cover a good portion of
> existing scripting languages, markup languages etc....
>
>
> Leadership Succession
> ~~~~~~~~~~~~~~~~~~~~~
> - Due to increasing time constraints and an ever tightening
> schedule, I'm
> going to have to relinquish my duties as the leader of this
> sub-committee. I
> fully intend to remain an active member of this group and to
> help out as
> much as I can, but I'm afraid I just can't dedicate the time
> necessary to
> staying on top of all the discussion, making the concall
> agendas and leading
> the discussion on the phone. We can, however, continue to use
> Bowstreet's
> conference call facilities (which includes nice things such as call
> recordings to facilitate minute taking) indefinitely.
>
> - I'd like to select the new leader during this call and
> transfer over the
> leadership of the calls starting with our subsequent conference call.


(See attached file: MarkupSubcommittee050802.htm)

Title: Markup Sub-committee Conference Call, April 5, 2002

Markup Sub-committee Conference Call, May 8, 2002

 

• Attendees: Gino Filicetti, David Taieb, Rich Thompson, Jane Dynin, Jeff Broberg, Lothar Merk, Carsten Leue

Sytle Sheets

• Jeff suggested that we should use a WSIA namespace for the CSS classes that we are defining since these classes will be used in WSIA as well
• Rich thinks we should have two namespaces, and envisions things moving back and forth between the WSRP namespace and the WSIA namespace as they are designed and discussed.
• David asked if we need to provide default values for these styles. The consensus was that default values will NOT be part of the spec and instead will be left up to the implementation.
• Rich asks whether all producers NEED to use style sheets or CAN use style sheets.
• Consensus was reached that we should use a WSIA namespace for all of our CSS class names, using “wsia-“ as a prefix to the class name.
• Jeff is going to contribute more styles to our current list.
• ACTION: Consolidate the list the styles and rename them using the appropriate namespace (“wsia-“) after Jeff’s contribution is made.

 

Markup Tags

• The “problem” tags in both HTML and XHTML Basic were categorized into Disallowed and Discouraged subsets as follows:
  HTML:
      Disallowed: base, body, frame, frameset, head, html, title
      Discouraged: link, meta, style
  XHTML
      Disallowed: base, body, head, html, title
      Discouraged: link, meta
• Carsten wants us to be absolutely sure that the discouraged tags will really work inside of the <body> tag in all (most common) browsers.
• Question, does the inclusion of a DISALLOWED tag invalidate the whole markup fragment?
• Consensus was that yes, this is true… however, we don’t want to require consumers to parse markup fragments looking for disallowed tags.
• Jeff: It is not a requirement for the consumer to parse the output of the producer; however, we do want to leave room for this if a consumer wants to. Do we want to provide a mechanism for the consumer to inform the producer that an error occurred?
• We should spec that its not required to parse the markup and leave the rest open to interpretation.
• Rich: This is a definition of conformance; does not dictate any behaviours and that’s how it should be specified.

 

Secure Resources

• The two scenarios (see agenda) envisioned can actually be merged into one.
• Carsten: All we need to say is that secure resources are accessed through the consumer by way of all links being rewritten to point back to the consumer, and then the consumer can choose whether to do a straight proxy or cache the resources if need be.
• Rich, how does the producer indicate that a resource needs to be proxied?
• Jeff, Carsten, Gino… the consumer is in a better position to determine whether a resource needs to be proxied for a particular client.
• Rich: Need to be careful when talking about the proxying capability and require that the same security needs to be applied with respect to privacy and access control that the rest of the system applies.

 

URL Rewriting and Namespace Encoding

• Same 3 scenarios (see agenda) were considered. The 2^nd scenario is seen as the most ideal and easiest to implement.
• Jeff suggested that scenario 1 and 2 could be combined where the consumer could OPTIONALLY send a prefix, and if it wasn’t sent, the producer would use the standard one.
• Carsten: Then there wouldn’t be a reason to have a standard prefix.
• Carsten: The advantage of having a standard prefix is that the search and replace code could be written once and made into a standard library.
• 3^rd scenario was dismissed outright as being technically infeasible.
• Rich: A deterministic heuristic does not exist for finding URLs that are dynamically constructed in Javascript.


• There are two mechanisms that can be used to demarcate a URL
• An escape sequence is used that can be searched for and replaced by the correct rewritten URL.
• Explicit tags are put into the markup to indicate URLs that need to be rewritten. And then the markup will have to be parsed in an XML parser to find the necessary spots to do the rewriting.
• Consensus was reached that the escape sequence alternative would perform better and be easier to implement.
• Rich: A 4^th scenario brought up in the WSIA Embedded use case was to have the aggregator tell the remote portlet URL prefix to use, and have the remote portlet rewrite all necessary URLs and then return the markup which would be ready for immediate inclusion in the page.
• Rich: A combination of scenarios 2 and 4 can be where a producer can indicate whether is CAN rewrite the URLs if chosen to do so (scenario 4). But the Consumer is REQUIRED to rewrite the URL if the Producer will not (scenario 2).

 

Leadership Succession

• Jeff: Will look into asking one of his team members (Chris Braun) who is involved in the JSR169 Markup subcommittee and has been following the WSRP committees closely if he’d be interested in taking up the leadership duties of the group. He’ll get in contact with Gino directly.
• No one else on the call was interested in the job.