RE: [wsrp] [CR310] - Add doctype fields

[Rich Thompson <richt2@us.ibm.com>]

The public parameter concept doesn't
fit well with a bidirectional flow of data. However, I would agree that
the proposal for doctype does fit well with the public parameter model
(Portlet requests Consumer supply a particular piece of data and has reasonable
fallbacks should the Consumer choose to not supply it).

Subbu, would the spec defining such
a public parameter for Portlet reuse satisfy your use case?

Rich

"Andre Kramer" <andre.kramer@eu.citrix.com>

03/23/05 09:06 AM

To	"Subbu Allamaraju" <subbu@bea.com>, <wsrp@lists.oasis-open.org>
cc
Subject	RE: [wsrp] [CR310] - Add doctype fields

What prevented us leveraging the new public parameters
feature for CC/PP
was its inability to return a value. Maybe that should be addressed so
that extensions could use the (render) parameter extension mechanism?

Regards,
Andre

-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com] 
Sent: 23 March 2005 14:00
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] [CR310] - Add doctype fields

I agree with you both on the concern about proliferation of these 
parameters.  Any thoughts on how such well-known extensions should
look 
like?

Subbu

Michael Freedman wrote:
> Additional good questions that add to my reservation of adding this
to

> MarkupParams.  I think I would rather us begin to define well-known
> extensions for consumers/producers to take advantage of if/when 
> necessary.  Otherwise I worry the parameter list will continue
to grow

> over time as we find new use cases for additional information.  [By
the 
> way, this was also at the root of my questions/concerns about adding
CC/PP]
>      -Mike-
> 
> Rich Thompson wrote:
> 
>>
>> Interesting point, but one could easily argue this is an issue
with 
>> what the framework makes available to the component rather than
a 
>> general issue (i.e. that decision could be easily changed).
>>
>> Thinking about this further led to the following questions:
>>
>>    1. Isn't this an html specific issue (i.e. doctype
in addition to
>>       mimetype)? If so, that reduces its fundamental
value to me.
>>    2. Wasn't the introduction of several doctypes part
of a
>>       recognition on the part of the html standardization
group that
a
>>       significant body of legacy web sites existed?
Should this be
>>       carried forward into the WSRP-enabled portlet
world,
>>       particularly in light of this quote from
our Primer; "WSRP
>>       raises the bar of conformance for this standard
in many
respects
>>       for what constitutes a good or effective
portlet
implementation.
>>       The specification makes specific recommendations
regarding
>>       markup fragment rules, representing state,
ensuring security,
>>       etc., with an eye toward maximizing the usefulness
and
integrity
>>       of portlet services."? If WSRP is truly
raising the bar, it
>>       seems advocating adherence to the strict
doctype should be part
>>       of that.
>>    3. Are there any problems if a portlet generates
a fragment of
>>       "strict" html which gets included
on a page with the
>>       transitional html doctype?
>>
>>
>> Rich
>>
>>
>> *Michael Freedman <Michael.Freedman@oracle.com>*
>>
>> 03/17/05 06:13 PM
>>
>>                
 
>> To
>>                
 wsrp@lists.oasis-open.org
>> cc
>>                
 
>> Subject
>>                
 Re: [wsrp] [CR310] - Add doctype fields
>>
>>
>>
>>                
 
>>
>>
>>
>>
>>
>> I think the answer to whether the "consumer" knows the
doctype is a 
>> qualified "no".  Take for example someone who wants
to build portlet 
>> support into a generic application development platform.  The
platform 
>> would expose a developer friendly API for using/manipulating 
>> consumer-side use of portlets and hide the gory details of 
>> communicating with [remotw wsrp] portlets.  In such an environment
>> there is a clean and distinct separation between application code
that 
>> describes the structural rendering of the a consumer response
and any

>> given component in that structure that provides a portion of the
>> rendition.  Because doctype is likely just markup expressed
in the 
>> page, such components may find it difficult if not impossible
to 
>> determine what it is.  I.e. whereas you can get the locale,
mimetype 
>> and characters set from a servlet response you can't get the doctype.
>>    -Mike-
>>
>> Rich Thompson wrote:
>>
>> This change request raises a couple of questions for me:
>> 1. Will the Consumer always "know" the doctype for what
will be 
>> returned to the user agent at the time it invokes getMarkup? I
think 
>> the answer is "yes", but we should review this carefully.
>> 2. Are there other characteristics of the aggregated page that
the 
>> Portlet could make good use of? Currently we have locale, mime
type 
>> and character set ... any others?
>>
>> Rich
>>
>> *Subbu Allamaraju **_<subbu@bea.com>_* <mailto:subbu@bea.com>
>>
>> 02/02/2005 11:19 AM
>>
>>                
 
>> To
>>                
 _wsrp@lists.oasis-open.org_ <mailto:wsrp@lists.oasis-open.org>
>> cc
>>                
 
>> Subject
>>                
 Re: [wsrp] [CR310] - Add doctype fields
>>
>>
>>
>>
>>                
 
>>
>>
>>
>>
>>
>>
>> For the reasoning, I meant to say
>>
>> "Due to the legacy nature of web, some portal sites are designed
to
>> generate either _strict_ or quirks mode HTML ..."
>>
>> I missed "strict" in my request sent to Rich.
>>
>> Subbu
>>
>> Rich Thompson wrote:
>> >
>> > Document: Specification
>> > Requested by: Subbu Allamaraju
>> > Section: 6.1.9 MarkupParams Type
>> > Page: 31
>> > Old Text:
>> > New Text:
>> >
>> >     [O] string        doctype
>> >
>> >    - doctype: The value of the PUBLIC ID of the
DOCTYPE
declaration, if
>> > any, used by the Consumer. Consumers using legacy or strict
style
HTML
>> > may supply the DOCTYPE. Producers MAY honor such DOCTYPE
while
>> > generating markup.
>> >
>> > Document: WSRP1.0
>> > Section: 5.1.10 MarkupType Type
>> > Page: 20
>> > Old Text:
>> > New Text:
>> >
>> >      [O] string      doctypes[]
>> >
>> >     - doctypes: An array of DOCTYPE declarations
that the Portlet
can
>> > support.
>> >
>> > Reasoning:
>> >
>> > Due to the legacy nature of web, some portal sites are designed
to
>> > generate either or quirks mode HTML markup and expect browsers
to
>> > interpret the markup accordingly. Browsers use the HTML DOCTYPE
>> > declaration to indicate browsers which mode to use. For example,
the
>> > following DOCTYPE declaration can be used for strict
interpretation:
>> >
>> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
>> >      _"http://www.w3.org/TR/html4/strict.dtd"_
>> <http://www.w3.org/TR/html4/strict.dtd>>
>> >
>> > During an earlier discussion, the following issues have been
identified:
>> >
>> > a. Consumers do not know whether a portlet can generate markup
in a
>> > given DOCTYPE.
>> > b. Portlets do not know what kind of DOCTYPE to expect.
>> >
>> > The above changes address these issues. Please note that,
in order
to
>> > preserve backwards compat, both these elements are optional,
and
the
>> > behavior is unspecified when the doctypes are not supplied
by
either 
>> side.
>>
>>
>> To unsubscribe from this mailing list (and be removed from the
roster

>> of the OASIS TC), go to 
>>
_http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgro
up.php_.
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org