- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 18 Nov 2004 23:19:47 +0000 (UTC)
- To: Daniel Veillard <veillard@redhat.com>
- Cc: public-xml-id@w3.org
On Thu, 18 Nov 2004, Daniel Veillard wrote: > On Thu, Nov 18, 2004 at 03:08:46PM +0000, Ian Hickson wrote: > > On Thu, 18 Nov 2004, Daniel Veillard wrote: > > > On Thu, Nov 18, 2004 at 02:06:41PM +0000, Ian Hickson wrote: > > > > > > > > Please ensure the test suite contains a test where the following: > > > > > > > > xml:id=" te st " > > > > > > > > ...is shown to cause its element to have ID "te st". > > > > > > No, the result is not an NCName, this shoul;d not generate an ID. > > > > That doesn't matter, see xml:id section 4 paragraph 10: > > > > | The xml:id processor performs ID assignment on all xml:id attributes, > > | even those that do not satisfy the enumerated constraints. > > I actually strongly disagree with this. I have seen enough XPointer/XSLT > and C14N horrors due to the "lax" behaviour of XPath-1.0 IDs ! When you > start doing digital signatures based on something which should have > raised an error but that the software didn't even care to report, you're > back to the random processing mess we tried to avoid with XML-1.0 :-( Well, in the case of xml:id it isn't random at all, the processing is fully defined. So I don't think this causes any kinds of random processing mess. But it should definitely be tested. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 18 November 2004 23:19:50 UTC