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:
Isn't this an html specific
issue (i.e. doctype in addition to mimetype)? If so, that reduces its fundamental
value to me.
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.
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 <>
02/02/2005 11:19 AM
To
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">
>
> 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_workgroup.php.
