[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:[email protected]>
>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]