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"
<>
03/23/05 09:06 AM
To
"Subbu Allamaraju"
<>, <>
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:]
Sent: 23 March 2005 14:00
To:
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 <>*
>>
>> 03/17/05 06:13 PM
>>
>>
>> To
>>
>> 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 **_<>_* <mailto:>
>>
>> 02/02/2005 11:19 AM
>>
>>
>> To
>>
-open.org_ <mailto:>
>> 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:
For additional commands, e-mail:
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
