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

Note that I have copied xhtml2-issues so that this is tracked in the 
issue handling system.

I understand that you disagree with the working group's response to your 
issue, and will record your objections in the issue tracking system.  I 
have included some further explanation below, but do not imagine that it 
will change your opinion.

Jim Ley wrote:

>On 5/25/05, Shane McCarron <shane@aptest.com> wrote:
>
>
>  
>
>>XHTML defers to XML for well formedness and validity checking. 
>>XML leaves this up  to the implementation, so we do too.
>>    
>>
>
>Please change the document to include this information, currently it
>is not specified at all, I do not accept this response as sufficient,
>indeed I do not believe it answers the issue at all.
>
>However, if the case is that the document will state that tehre is no
>defined error processing for invalid and non-well-formed content, then
>this is not acceptable to me, user agents cannot interoperate in any
>way in this situation - see similar issues raised by many other groups
>against numerous W3 specifications, the arguments are the same.
>  
>
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.

>  
>
>>>The 7th criteria, if standalone="yes" was set, this would be a WFness
>>>error, does this criteria describe error recovery, or is this
>>>behaviour only for non-standalone XML documents where the entity may
>>>have been set in the external subset?
>>>      
>>>
>>We are not saying that external subsets have to be used.  An 
>>implementation may, for example, have arcane knowledge of 
>>popular general entities.
>>    
>>
>
>So a document that is not-well formed must still be rendered correctly
>by an XHTML 2.0 user agent?   I understood from your previous response
>that XHTML defers to XML in such respects, I understood XML said
>normal processing could not continue - this appears to be incompatible
>with your previous response.  I also reject this response as it
>appears to be technically unsound.
>  
>
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:

    When rendering content, user agents that encounter characters or
    character entity references that are recognized but not renderable
    should display the document in such a way that it is obvious to the
    user that normal rendering has not taken place.

Hopefully this constraint is less objectionable to you.

>>>10.  Why MUST user agents use a particular visual representation if
>>>they do not support CSS, and why is this restriction only on visual
>>>presentation, (there are aural CSS settings in the default
>>>stylesheet.)
>>>
>>>I don't see the need on placing any restriction on what a conforming
>>>UA may do - I certainly do not agree with making a UA non-conforming
>>>purely because it doesn't implement CSS and allows users to pick their
>>>own colours for links!  (I realise that 10 only says SHOULD, but the
>>>introduction to 3.2 says MUST.)  In any case I don't even agree that
>>>this is a SHOULD for a conforming UA.
>>>      
>>>
>>HTML has traditionally described default presentational behavior.
>>    
>>
>
>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. 

>> What we have
>>done with XHTML2 is 1) described this behavior using a well defined standard
>>(CSS) and 2) relegated those default presentation behaviors to an appendix.  
>>    
>>
>
>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, 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. 

>>We agree that there are many audiences beyond visual user agents.
>>    
>>
>
>So please either provide required renderings for these other types of
>user agent. Or note specifically in the specification that non visual
>user agents are not required to render it in that way.
>  
>
We have attempted to address this concern.  See above.

>>>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. 
>>    
>>
>
>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.

>>>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. 
>>    
>>
>
>This is not true though, the example of SCRIPT and STYLE from HTML are
>good examples of why it's not appropriate.  Or of course Bjoern's
>example with SVG.  I reject this response and believe good technical
>arguments of how child content rendering specifically breaks
>compatibility have been given.     I reject this comment, please
>change the specification in line with the original comment and
>disallow child content rendering.
>  
>
We are not planning to make that change, but we have recorded your 
objection.

>>>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.
>>    
>>
>
>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.  In XHTML 2, 
if your concern is that the meaning of a document might change if a 
certain facility is not available, you can use the fallback mechanisms 
associated with the src attribute... for example:

<p src="externalDoc.svg">I can't render this section - no SVG support</p>

Then any embedded content in that fragment would only be generated if 
the processor knew what to do with SVG content.  Well not optimal, this 
does permit substantial flexibility.  For example, I could also do:

<p src="externalDoc.svg">
   <p src="externalDoc.png">
      <p src="externalDoc.gif">
         I can't render this section - no graphics support
      </p>
   </p>
</p>

Note, however, that in a hybrid document type that merged SVG with 
XHTML, this would be a little counter-intuitive for content developers.  
I appreciate that you have identified a situation where you would not 
want the content to be rendered.  I could show many many examples where 
I would want it to be rendered.  The book is not closed on this issue, 
but at this time the Working Group has no ready solution that will 
satisfy both camps.  We would certainly welcome a proposal to that end, 
if you have one.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 27 May 2005 18:34:31 UTC