Hmph. Visa's case, I guess, is that their "id" attribute is not an ID.
<rant> This is technically true, but they're acting like Humpty-Dumpty, who claimed a word meant whatever he wanted it to. "id" is a widely used term with a generally accepted connotation, and they're using it differently, which is simply begging for misinterpretation and confusion. I gather that the situation is made worse by the fact that it would be useful for this element to have an ID. Thanks to their misappropriation of a common name, it appears to, but in fact does not. In other words, what they've done is: 1) apparently completely legal, and 2) misleading and useless. In short, a stupid programming trick. Now, I could be wrong about the legal bit. I haven't looked at their spec, but if they're claiming to have an ID attribute on their element that can be used in a DSig Reference, they're flat-out wrong, whether willfully or due to ignorance or incompetence. I know you're not the first to encounter this; that's why I'm ranting. </rant> > -----Original Message----- > From: Slava Kostin [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2003 8:13 AM > To: Jesse Pelton > Subject: Re[2]: [xmlsec] XPATH and Visa 3D-secure specification > > > ...they don't think that's a mistake with > definition of "id" attribute as "CDATA" :-( > And element CDATA have not to satisfy with name production rules. > > I'm not the first who've such problem, unfortunately. _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
