W3C home > Mailing lists > Public > www-html-editor@w3.org > April to June 2005

Re: XHTML 2.0 - 3.2 Conformance Requirements (PR#7651)

From: Jim Ley <jim.ley@gmail.com>
Date: Fri, 27 May 2005 23:21:54 +0100
Message-ID: <851c8d310505271521654dfe4@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: w3c-html-wg@w3.org, www-html-editor@w3.org

On 5/27/05, Shane McCarron <shane@aptest.com> wrote:
> I understand that this is unacceptable to you, and have made a note to
> that effect.  The HTML Working Group has decided that it cannot
> legislate how XHTML processors (user agents, validators, etc) will
> behave in the presence of data that is NOT a conforming XHTML document.
> We have attempted to clearly define what an XHTML document is, and
> certainly have indicated that an XHTML document must be valid.  The
> processing of invalid content has NOTHING TO DO WITH INTEROPERABILITY OF
> DOCUMENTS, since by definition invalid content is not interoperable.

One of the original issues showed exactly a situation where you are
saying what should happen with a non-well formed document.   Please
explain the above comments in light of that situation.

Standalone="yes" and an unknown entity is a well formedness error, So
a user agent cannot meet both 1 and 7 in that situation.  Please
clarify the document so as this situation does not lead to
incompatibility between must requirements.

> You are correct that the 20040722 draft specifies an optional behavior
> (should) that is incompatible with XML's requirements for processing.
> The current version (not yet public... any minute now) says:

Could you please explain how my issue was both rejected, and accepted
resulting in a change of text at the same time?  Was it actually not
rejected, but agreed with, or what?

> >Could you point me to a previous HTML WG document that defined
> >presentational behaviour?
> >
> >
> Sure...  http://www.w3.org/TR/html4/  Note that in that document, as in
> this document, the presentation is a suggestion, not a requirement
> (should, not must) that is meant to help ensure that there is document
> portability and interoperability.

I can find nowhere in that specification information on rendering.  

I have also yet to see any attempt to explain the decision and to
satisfy me about the issue of a user agent being non-conformant
because it allows a user to choose to render text in red.  (I am also
confident that this will not get passed a WAI review, as it's clearly
inaccessible to require a particular rendering.)

Equally, the use of SHOULD (of RFC 2119) as part of a MUST  is
confusing please clarify.

> >I cannot see how this is a response to my issue, and I therefore
> >reject it.  No text has been clarified, you have not explained why
> >it's appropriate to make a user agent non-conforming for allowing uses
> >to choose a colour for links.
> >
> >
> There is nothing in the text that 1) requires a user agent to use this
> style sheet,

"3.2 A conforming user agent must meet all of the following criteria...
10. In the absense of a visual presentation should be as if the user
agent used the CSS stylesheet specified in Appendix H."

This is clearly a requirement, the only way the MUST can be fulfilled
is by rendering it in that way.

> or that 2) says user agents could not extend the behavior
> defined in Appendix H if they wanted.  However, in the interests of
> clarity, I have changed the clause to read:
>    In the absence of a style-sheet, including user agents that do not
>    process style sheets, the default visual presentation should be as
>    if the user agent used the CSS style sheet specified in Appendix H.

This is no clearer and is still a MUST, a MUST for visual, or any
other rendering, is inaccessible and not appropriate.  Please change
the specification so as rendering is not a MUST, or explain in
technical details why that a particular visual representation is
required by XHTML 2.0 user agents.

> >Where in the specification can I find this information?  I reject the
> >response to this issue as it has failed to respond to the issue,
> >you've merely provided some other explanatory information, the issue
> >was are SVG fragment identifiers - e.g. of the type
> >#svgView(viewBox(0,200,1000,1000)) legal or not in mixed namespace
> >documents?   I appreciate this may be the domain of the CDF WG,
> >however I feel it's important that XHTML 2.0 does not restrict the
> >possibilities for interopability in mixed namespace content.
> >
> >
> As long as there is some element with an attribute that is of type ID
> that has a value corresponding to that fragment identifier, it is
> legal.  I must not properly understand your question.

I fail to see how I can make my issue clearer, the SVG Fragment
identifier above is valid, and is nothing to do with things of type ID
- SVG allows many fragment identifiers, one of which is the viewBox
described above.  Instead of restating irrelevant and incorrect
information, when you do not understand the issue, please ask for
clarification.   It is clear that 10 months after the original issue
is not timely manner to ask for that response.
> >I am sorry if I was unclear, the host language was XHTML 2.0,
> >something of this sort of structure:
> >
> ><html ...xmlns="http://www.w3.org/2002/06/xhtml2"  >... <svg
> >...xmlns="http://www.w3.org/2000/svg"> ... <foriegnObject><html ...
> >xmlns="http://www.w3.org/2002/06/xhtml2" >
> >
> >The point being that there are XHTML 2.0 elements within elements of a
> >namespace that are not understood, my concern in the issue is that by
> >rendering the XHTML 2.0 elements inside the SVG fragment the meaning
> >of the document will change, and that in such a case we do not have
> >acceptable compatibility with XHTML 2.0 only user agents.   I
> >therefore reject the response to the issue, perhaps that was because
> >it wasn't clear, in which case please raise another issue.
> >
> >
> I think your issue was clear to everyone who discussed it.

The response to the issue made no technical sense if they did, as it
claimed the host language was SVG, when the host language was XHTML
2.0, in light of this please consider this a seperate issue, and
return it to the working group for discussion.   I consider this a new
issue, please provide me a reference so I can track the response.

Received on Friday, 27 May 2005 22:21:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:54 UTC