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

Jim Ley wrote:

>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.
>  
>
I believe I included the updated text in my response.  In case I did 
not, it is:

    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.

You can see this, btw, at 
http://www.w3.org/TR/2005/WD-xhtml2-20050527/conformance.html#s_conform

>>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?
>  
>
Your comment had nothing to do with that change.  At least, not 
according to the records I could find.  Also, unfortunately, your 
comment had many many semi-related issues in it.   The working group 
does not have a great mechanism for dealing with comments like that - in 
general we need to split them up.  However, when they are 
inter-dependent we cannot do that.  Regardless, I hope the text change I 
included above clarifies the constraint.

>>>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.)
>  
>
Ummm.  I included information on that in my last response, along with 
the text of the constraint.  Again, to reduce confusion, the "should" 
constraint in question is:

    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 constraint is a SHOULD and indicates what SHOULD happen by 
default.  Of course any user agent is 1) free to ignore this constraint, 
and 2) free to allow user customization, since that would no longer be a 
default.

>Equally, the use of SHOULD (of RFC 2119) as part of a MUST  is
>confusing please clarify.
>  
>
Errr - there is no must in that sentence.

>>>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.
>  
>
Ahh - I perceive the source of your confusion.  In my experience, 
English is a weak language for expressing constraints.  However, believe 
me when I say that the "must" in the introductory sentence is not 
distributive (as in math) to the child bullet points.  You will see in 
the new draft that we have (annoyingly) highlited all of the actual 
constraints in the document.  We may have missed some, but not in that 
chapter. Regardless,  I will see if I can find a way to rephrase that so 
there is less confusion.  Thanks for pointing it out. 

>>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.
>  
>
Well - it's not a MUST.  But I will see if I can change the text so that 
you don't think it is a MUST either.

>>>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.   
>
Umm.  I did.

>It is clear that 10 months after the original issue
>is not timely manner to ask for that response.
>  
>
Neither is "never", which is when it could have happened.  We are doing 
our best here.  If you are involved in W3C activities then you know how 
the volunteer process works.  And for the record, this is not *me* 
understanding or misunderstanding anything.  This is the working group's 
position.  I am just conveying it to you.  I am happy to take your 
slings and arrows, but don't for a moment think that I am operating on 
this stuff alone.

>>>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.
>  
>
I'll get right on that.

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

Received on Saturday, 28 May 2005 00:12:16 UTC