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

* Shane McCarron wrote:
>> What does the first criteria mean?
>> 
>> | The user agent must parse and evaluate an XHTML 2 document for
>> | well-formedness. If the user agent claims to be a validating user 
>> | agent, it must also validate documents against a referenced 
>> | schema according to [XML]. 
>> 
>> It doesn't say anything about what should happen if the UA finds a WF
>> or schema violation.  What should happen?
>
>XHTML defers to XML for well formedness and validity checking.  XML
>leaves this up to the implementation, so we do too.

Could the HTML Working Group please either point out the sections in the
draft under discussion that clearly answer such questions or explain in
detail the changes that have been made in response to the comment? There
is no point in simply answering questions as the reviewer is hardly the
only one wondering about the specific item, or, if that is the position
of the Working Group, this needs to be pointed out in the response.

>From your response I understand that XHTML 2 does not define processing
of non-compliant content at all, neither directly nor indirectly through
normative reference. That's not acceptable, please define processing in
case of error conditions in detail, otherwise user agents cannot easily
interoperate.

>> Does the Fragment identifier constraint mean that with mixed namespace
>> content, I cannot use the fragment identifiers of the other namespaces
>> in an XHTML document to identify part of an SVG image say?
>
>Any attributes of type "ID" are legitimate fragment identifiers.  If SVG has
>such an attribute, it would be a legal target.

The requirement only applies "When a user agent processes an XHTML 2
document as generic XML", no XHTML 2 user agent will ever do that as
it is required to "process" XHTML 2 documents as defined in XHTML 2;
clearly, user agents that do not conform to XHTML 2 are out of scope
of XHTML 2, please remove the requirement.

Semantics of fragment identifiers are defined in the XHTML 2.0 media
type registration, no media type for XHTML 2.0 has been proposed yet,
please propose a media type for XHTML 2.0 by following the relevant
IETF procedures and define fragment identifier processing there.

>> Is processing children of unknown elements sensible - this is what led
>> to the script cargo-cult of -- hide from old browsers gobbledygook.
>
>The purpose of child content rendering is to enable extensibility without
>breaking compatibility with legacy browsers.

As Jim pointed out, it does not enable but rather prevent that. Please
change the draft to enable introduction of elements with content that
should not be rendered as text.

>> Also what happens with a mixed namespace document where you have an
>> SVG fragment with embedded XHTML2 inside a foreignObject, in what
>> situations should the XHTML portions be rendered - does the combined
>> document really make "sense" without the SVG elements, or will this be
>> simply forcing authors to go to extreme lengths to ensure their
>> documents degrade.  I feel the exact opposite of the above conformance
>> requirement would make more sense.
>
>Well - this situation is different.  Here you are talking about XHTML being used
>in a different host language.  In that situation, the conformance rules of that
>host language would kick in.

So the HTML Working Group's position is that SVG needs to define how
XHTML 2 content is processed in SVG's foreignObject element? SVG 1.2
does not do that and the HTML Working Group did not send comments on
SVG 1.2 to this effect, so it seems neither SVG nor XHTML 2.0 will
define how to use them together; that does not make much sense to me.
Please define XHTML 2 processing when XHTML 2 content is included in
SVG documents.

The same goes for SVG content included in XHTML 2 documents of course.
Clearly, per the latest draft 

  <html ...>...<svg ...><script>script content ...

XHTML 2 user agents that do not support inline SVG would render the
script content, that makes no sense at all as pointed out above.

Received on Thursday, 26 May 2005 00:41:26 UTC