Re: Agenda+ Review XHTML module for ARIA

I have added the XHTML2 working group to this thread, since it is a good 
discussion for that group.  My comments on this message are at the end.

Simon Pieters wrote:
> On Wed, 30 Jul 2008 17:53:03 +0200, Shane McCarron <shane@aptest.com> 
> wrote:
>
>>> We could easily pull the above comment; it is a comment.
>> I strongly disagree.  If your purpose is to create an XHTML Family 
>> markup language, even one that is an example, then XHTML M12N defines 
>> the pattern for "minting" XHTML family markup languages, and requires 
>> the definition of an FPI.  See 
>> http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_naming_rules 
>>
>
> Well perhaps we should change M12N then so we don't have to go chasing 
> new FPIs that the W3C invent and break compat with older versions of 
> browsers.
>
>
>>> The harder decision to make is about pulling the entire sub-appendix
>>> giving the SGML Open Catalog entry.  As I understand it, the point
>>> of the catalog entry is to bind the FPI to 'physical' stuff.  I had 
>>> been
>>> thinking of suggesting we strike this sub-appendix, but it was an 
>>> easier
>>> edit to add the note about "URIs not final" and we do need a URI for 
>>> the
>>> module in any case.
>> You don't need to include that if you don't want to.  We always do, 
>> just because it is good practice for people who are building catalogs 
>> and helps them out.  It is not a requirement.
>>>
>>> I suppose my proposal for the present release would be to strike the 
>>> comment Simon
>>> quoted above, remove the catalog entry appendix, and fix any ensuing 
>>> breakage
>>> as necessary in future drafts.  I will accept discussion on this point
>>> on today's call.
>> Its not just a comment - it is comment that, when combined with a 
>> conformance clause, shows how to formally reference the markup 
>> language you are defining.
>>> We will want a specific profile for testing
>>> and I think it should be close to some developmental drop of XHTML 1.2.
>> I think that's a bad idea - for testing purposes you should be using 
>> your minimal test environment.  Testing against some unknown, 
>> undefined, future markup language that has no schedule seems risky at 
>> best, disastrous at worst.
>
> I don't follow.
XHTML 1.2 is not something that is going to be available in a 
predictable timeframe.  Never make your research dependent upon someone 
else's research.  In this case, never make your testing dependent upon 
technology that has no schedule.
>
>
>>> In my opinion the debate over FPI management should take place over the
>>> publication of XHTML 1.2, not WAI-ARIA.  The driver we give here is 
>>> just
>>> and example to document the mechanics, not reflecting PFWG decisions 
>>> about
>>> what to include in the profile beyond WAI-ARIA.  That's a job for
>>> XHTML2 WG and XHTML 1.2.  That may or may not merit the coinage of a 
>>> new
>>> FPI, but not before.  Even then such coinage is subject to community 
>>> feedback
>>> about FPI management.
>
> Well then I'll forward my feedback to the XHTML2 WG if/when they have 
> minted an FPI for XHTML 1.2.
>
>
>
>> Could be.  I don't think there are any options nor any debate about 
>> this.  New markup languages get new FPIs.  'Cause we said so.  We are 
>> not in a position to change the conformance requirements of XHTML 
>> Modularization right now.
>
> You're causing grief for browser vendors. See 
> http://annevankesteren.nl/2007/12/xml-entities 
The XHTML Family supports a well defined collection of entities.  You 
can 1) dereference the DTD from the DOCTYPE declaration to learn them, 
or 2) you can say "that's a well known FPI, I know what that means" or 
3) you can say "That FPI matches the pattern for XHTML Family FPIs, 
which is well know, and I know what that means".  Finally, you could do 
1) when 2) or 3) was not true, but then learn the FPI and treat it as 2) 
from then on.  Or, you could just do what XHTML M12N says you should do 
in this case, which is in production 6 of clause 3.5 of XHTML M12N.  
There are lots of solutions to the XML Entity problem.  But that problem 
is not really relevant to the question of whether FPIs have meaning and 
whether creating new ones is problematic.

Let me put this another way.  If there were no DOCTYPE - no declaration 
of any type about what version of what markup language a document was 
written in, what would a browser do? I mean, I know what it would do 
today if it were served as text/html... use some broken tag soup parser 
that has been around for ages and try to guess what I meant.  Reverse 
engineer a DOM tree that is probably right, but maybe not.  'cause it 
guessed.  Makes me crazy.  Makes most people crazy.  It's the best 
reason for the HTML5 spec.  Lock down the broken behavior so it makes 
people predictably crazy.

But what if it were XML and served as application/xhtml+xml?  What would 
a user agent do then?  Presumably it would follow the rules as set forth 
in XML for parsing, the XML DOM rules for DOM generation, and for 
elements in the XHTML namespace, it would look to XHTML M12N for 
behavior. Probably with some arcane knowledge based upon historical 
practice, because that's just how programmers work.  But in general it 
would follow the rules for behavioral requirements for XHTML...  And 
that's exactly what it should do.

If there were a DOCTYPE declaration, what would it do differently?  If 
that DOCTYPE adheres to the naming requirements in M12N and matches the 
pattern for XHTML Family, then it should do the same thing.  If it has 
some inbuilt knowledge about some XHTML family document types and wants 
to do something special for them, I suppose that's okay too.  But the 
default rules can and should apply in all cases for all unknown family 
members.  That's what the recommendations say, and I am pretty sure we 
meant it when we wrote them.

What's the alternative?  Have inbuilt knowledge about a handful of 
predefined markup languages based upon FPIs, and then fail to process 
new members of the XHTML Family?  That is certainly a violation of the 
spirit of the requirements for user agent conformance in M12N.  What a 
user agent that claims to support XHTML must do is say "oh, this is 
XHTML family. I know the rules for that" and just deal with it. 

FWIW, the XHTML2 Working Group "mints" new FPIs all the time.  I am 
saddened to learn that this is a problem for browser vendors. 

-- 
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, 30 July 2008 17:34:13 UTC