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

I need to apologize.  I did not mean that I was looking for text for 
this one small section of the document. I could think of many perverse 
situations for every element (what should a browser do when it finds a 
div inside of a span?  a div inside of a p?).  The point I was trying 
and failing to make earlier is that it is impractical to attempt to 
address all of these.  Actually, I maintain it is by definition 
impossible. My work with imaginary numbers was a long time ago (high 
school math), but the number of possible correct usage combinations of 
XHTML 2 content is ~infinite.  The number of correct + incorrect usage 
combinations is ~(infinite ^ infinity)...  And for every pathological 
case I can come up with, I bet there are 100 that I might miss.... an I 
find pathological edge cases for a living.

Lachlan Hunt wrote:

> I don't think anyone wants such extreme draconian error handling added 
> to XHTML 2, beyond that imposed by XML, but there is a requirement to 
> define what browsers must do, whatever that may be, upon encountering 
> erroneous documents.

But I maintain that if we are going to attempt to specify anything about 
processing incorrect behavior, then there must be a default, overriding 
behavior to handle pathological condition 10,007 - one of the first that 
we missed, but certainly not the last.

> Yes, that's correct because the fact is that authors will write 
> invalid XHTML, they will publish it on the web and browsers will be 
> forced to handle it somehow.  We only have to look back at how 
> differently browsers handle invalid HTML and how much reverse 
> engineering of error conditions has been done to know how important it 
> is for XHTML2 to define it properly from the start.

I guess I don't understand the reverse engineering bit...  are you 
saying it was bad in the past that browser vendors decided to try to 
emulate their competitors stupid behavior in the face of illegal 
content?  If so, I agree.  If you are suggesting we attempt to prevent 
that - that's tricky. Competitors want to differentiate their products.  
We are not in the business of stifling competition nor innovation.  At 
least I hope we are not!  Personally, I would want my user agent to have 
an option where it would bring up the source of the page in my favorite 
editor, taking me to the offending content.  That's a nice feature.  But 
of course I would only want that when I am developing my content.  When 
I am viewing someone else's content.... well, the user agent cannot go 
into "do what I mean, not what I say" mode.  That way lies madness.  And 
incompatibility, and the 90's... all over again.

>
>>  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.
>
>
> Interoperability is also about ensuring that different implementations 
> produce the same result given the same input, and considering that the 
> input *will* be invalid/non-conformant in many cases (that is, at 
> least, here in the real world), implementations need to know what to 
> do and need to implement such behaviour interoperably across the board.

But what they need to do is NOT process the content.  Seriously.  
Otherwise you end up with the nonsense we have had on the net for the 
last N years.... the situation you are bemoaning.   And you cannot just 
talk about section 24.2 (or whatever it is now - we have added 
chapters).   There is potential for erroneous usage EVERYWHERE. 

>
>
> As for a concrete proposal for this param element issue, there are two 
> choices that I can think of:
>
> 1. Any param element that is a child of an object element that occurs 
> after any sibling element other than caption, standby or other param 
> elements is to be ignored.  Param elements that are not children of an 
> object element are to be ignored.  If a param element is not empty, 
> its content is to be ignored (although it will still be present in the 
> DOM) and must not be rendered or executed (e.g. in the case of nested 
> handler/script elements) by default.
>
> 2. All param elements which are direct children of an object element 
> must be used, regardless of their position within the object element. 
> Param elements that are not children of an object element are to be 
> ignored.  If a param element is not empty, its content is to be 
> ignored (although it will still be present in the DOM) and must not be 
> rendered or executed (e.g. in the case of nested handler/script 
> elements) by default.
>
> The wording could probably be improved, but it's a start.

Yes, it is.  But in my opinion it need not be put into the spec.  Or 
rather, the correct content is already in the spec.  It is defined in 
the content model.  The content model says that param elements can be at 
some specific places and no other places.  Period.  We need not define 
content model restrictions in prose.  That's why we have formal grammars 
(or limited prose to augment the formal grammars).  And other, normative 
specifications (e.g., XML and DOM 2) to define how their parts in the 
puzzle work.  XML says how the content is parsed.  DOM 2 says how the 
DOM tree is constructed and maintained.  We cannot and should not 
specify additional constraints or requirements.  Those specifications do 
a fine job on their own.

Once we start down this road, we can't stop.  And, as I said above, it 
is impossible to get to the end of the road.  At least, that's what I think.

-- 
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 06:03:35 UTC