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

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.

<meandering>
Having been trained in linguistics, I'm personally of the opinion that 
any computer language, like human languages, will drift in its usage 
patterns, in its grammar and rules, and in its popularity.  XML will not 
be around forever in its present form; there is serious discussion about 
changing it significantly already, based on common practice and known 
pain points.  HTML, CSS, SVG... all these will go the way of Fortran and 
COBOL.

I'd be surprised if some dedicated application-specific markup for Web 
apps weren't widespread in the next 10 years, for example.  And I 
anticipate that that language could use many of the technologies we're 
developing now, like the DOM stuff, XHR, Access module, etc.

This has nothing to do with ids, other than to say that we don't know 
what the features of future grammars will be, so why put artificial 
constraints in the specs?
</meandering>


>  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.


> 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."

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Sunday, 10 August 2008 20:26:25 UTC