Re: (PFWG) ACTION-211 Query re: SVG Request for @order for Access Module

Doug,

Your comments cut to the core of a deep philosophical issue.  XHTML 
Modularization is a framework and techniques for defining interoperable 
XML modules.  XHTML Access is one such module.  The XHTML specifications 
have in general *never* defined required behavior in the face of 
incorrect usage - in particular when such behavior would be a violation 
of the underlying protocols or technologies.  Instead, we have used 
formal terms like "unspecified" or "undefined" as an indicator to 
application developers that it would be a bad idea to rely upon such a 
thing.  From XHTML 1.0:

    Unspecified
        When a value or behavior is unspecified, the specification
        defines no portability requirements for a facility on an
        implementation even when faced with a document that uses the
        facility. A document that requires specific behavior in such an
        instance, rather than tolerating any behavior when using that
        facility, is not a Strictly Conforming XHTML Document.


This standards development model is intentional, and as I think I 
mentioned I am irrationally biased in this regard.  It is hard for me to 
objectively consider other points of view because I am so opposed to 
trying to codify specific behaviors in the face of incorrect usage.  Its 
not that I don't understand that implementations might choose to do 
something when presented with an incorrect document.  I get it.  I just 
don't want to encourage it or define it in any way other than to tell 
document authors "don't do this - its wrong, the results are 
unpredictable, and your customers will not be happy."  I understand that 
there are people who disagree with me, and that those people feel we 
should carefully lock down the behavior so that it is possible to 
develop portable content even when that content is broken.  I just think 
that is silly.

I am not advocating breaking the web.  I think that is bad.  However, I 
am personally adamant in my position that we not *continue* to break the 
web.  That includes this case.  XML is extremely clear about IDs.  So is 
HTML 4.  There cannot be more than one ID with the same value in a 
document.  Period.  If I had been there when HTML 4 was being written to 
include ID, and had my way, we would have mandated that user agents 
refuse to process a document with such a violation except to say "your 
document is broken on line 245 - duplicate value of id attribute" and 
force the content developer to fix it.   If the web had worked that way 
from day one, we wouldn't have a steaming trillion page high pile of 
dung that is the modern web.   But I digress.

So, in specific response to your questions:

Doug Schepers wrote:
>
> Hi, Shane-
>
> Shane McCarron wrote (on 8/10/08 9:18 AM):
>> I appreciate what you are trying to accomplish, and I will leave that 
>> suggestion to the working group.  I have a strong bias against 
>> encouraging the behavior your are trying to permit.  This is an XML 
>> module, and XML does not permit duplicate IDs.  Period.  It would be 
>> inappropriate to use this module as written in any non-XML grammar. 
>
> Hm... why's that?  If a non-XML grammar has enough similarities to XML 
> that this module would be useful to it, then it seems appropriate 
> enough to use it there.

If there is such a language in the future, we can define the behaviors 
along with a new version of this module.  This module is for XML.  And 
that's it.  And as such, it should not document *successful* behavior 
that violates the XML recommendation.  I would be happy to say, if you 
like, that "As required by the XML Recommendation (ref) duplicate values 
for the ID attribute are not permitted, and therefore no behavior is 
defined for documents that violate that constraint."  I suspect you 
would not find that very satisfying.  Nor would other people.  In the 
past, we have decided that being silent on an issue rather than 
duplicating constraints enforced by underlying specifications is the 
wiser course.

>>  And
>> even in such a grammar (e.g. HTML4) duplicate IDs are not permitted.  
>> So I don't see why defining the behavior and therefore encouraging 
>> people to violate the rules is a good idea.  If it were up to me, I 
>> would codify that duplicate IDs are an error, and that the behavior 
>> of an implementation in the face of them is unspecified (formal, IEEE 
>> term... means its a bad idea, don't do it.  won't work portably).
>
> Why leave it unspecified?  It's not much more work to anticipate 
> common problems and explain what should happen in those 
> circumstances.  This is a big help to implementors, and it will make 
> it more likely that a well-detailed spec will be implemented, and that 
> the behavior will be interoperable.

Unspecified is a formal term.  This isn't about more work or less work.  
Its about what we are telling content developers.  It is also about our 
support for the underlying specifications... XHTML M12N and XML in this 
case.  Both of them say that such behavior is not permitted.  The DOM 
also does not permit it - it isn't even possible to discover a duplicate 
ID value via the DOM.  Or it should not be.  If I say "getElementByID" 
for a given ID, I get one.  And only one.  If there are multiple that 
match, I suspect the behavior is either 1) not what you expect or 2) not 
what I expect.  Either way, its bad.  And we can't fix it in the XHTML 
Access Module.

>> But, like I said, I value your input and know that I am dogmatic in 
>> this respect.  So I will leave it to the working group.
>
> Here's a compromise that may be more palatable to you (and is a bit 
> more precise than the original wording):
>
> "Also note: When processing a document with duplicate ids (e.g., an 
> invalid XML document), element groups based on targetid values may 
> contain multiple values, just like those of targetrole values." 

Honestly, I don't consider your suggestion a compromise.  Regardless, I 
am stepping out of the decision loop on this issue.  I am clearly very 
opinionated on this, and it is possible my opinions are out of sync with 
the current thinking of the XHTML 2 Working Group.

Thanks again for your hard work and suggestions.  I hope that this will 
get resolved at the next XHTML 2 Working Group meeting on Wednesday.

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

Received on Monday, 11 August 2008 22:19:38 UTC