Re: [XHTML 2] 24.2 Position of param elements (PR#7753)

(Speaking for myself, and not for the Working Group).

Anne van Kesteren wrote:

>
> On Tue, 24 Jan 2006 17:01:00 +0100, Shane McCarron  
> <xhtml2-issues@hades.mn.aptest.com> wrote:
>
>> 2) we don't define error behavior, in particular in the case of  
>> validation
>> errors. This is handled by XML.
>
>
> At one point the HTML WG looks at current implementations and at 
> other  points they simply miss the fact that implementations typically 
> do not  have validating parsers.

I disagree - the working group knows that most browsers do not 
validate.  Nor is there a requirement that they do.  But let's not have 
that argument - its circular and painful.

Let's instead try this one:  you cannot just say "add error conditions 
to XHTML2" - that's not a concrete proposal.  A concrete proposal would 
be "Change the specification to read... something".  Here's an example:

    Conforming user agents must refuse to process any document that
    claims to be an XHTML 2.0 document but does not conform to the
    requirements for a Conforming XHTML 2.0 Document.  When such a
    document is encountered, the user agent must by default present an
    error message and not process or render any of the content from the
    document.

I don't think that is the type of thing that anyone really wants, mind 
you.  But you really should present a concrete proposal.

You (and others) assert that it is incumbent upon a standard to define 
behavior in the presence of incorrect usage.  As evidence for this, you 
seem to claim that without this it is impossible to have 
interoperability.  That seems confused to me.  Interoperability is about 
how portable applications/documents function on conforming 
implementations.  The working group has attempted to define the 
requirements a portable application/document must adhere to (XHTML 2 
Strictly Conforming Document) and the requirements on a conforming 
implementation (XHTML 2 User Agent Conformance).

The drafts have all been very consistent in this; ever since the first 
drafts of XHTML 1.0 actually. A conforming document is one that is VALID 
and adheres to some other requirements.  If a document does not adhere 
to those constraints, then it is not XHTML 2.  It is an error for 
someone to assert that a document conforms when it does not adhere to 
those constraints.  If it is not XHTML 2, we don't know what it is and 
we cannot define processing rules for it...  Other than something 
draconian like the clauses above. 

On the implementation side, the drafts have required that conforming 
documents be processed.  Neither you nor anyone else would want the 
recommendation to say, for example, that an implementation was not 
permitted to process documents that conform to other specifications.  
Nor would you, I suspect, want the specification to overly constrain 
your ability to provide value add beyond the basic conformance 
requirements (user interface enhancements, user customization, etc.)   
Moreover, if the working group were to place constraints such as the 
ones above on implementations, it would force conforming implementations 
to validate (how else would you know if a document was conforming?)...  
and no one wants that.  The web is slow enough as it is.

But you and others clearly have some point too subtle for me to have 
grasped so far.  What am I missing here?

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

Received on Wednesday, 25 January 2006 02:10:21 UTC