- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Tue, 27 Jun 2006 20:26:58 +0100
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "Robin Berjon" <robin.berjon@expway.fr>, "Anne van Kesteren" <annevk@opera.com>, "Dave Hodder" <dmh@dmh.org.uk>, public-appformats@w3.org
Ian, > There's nothing wrong with the name "id". The idea that you might need to > manipulate XBL2 documents using Perl on the server side is crazy. Even if > you did, XBL2, HTML, SVG, and other such languages, which are all intended > to be "core" languages, can trivially be supported natively by your perl > library, and don't need to use "xml:id". I agree. I can see a use for something like xml:id in mark-up where the language used has no schema/DTD. But all the languages so far mentioned have 'schemas' defined for them. Any processing tool (like Perl on the server) would still need to know where the @id values are in the 'old' versions of those languages, so I'm having trouble seeing where the gain is. So xml:id appears to me to be useful as an additional tool for an *author* to use, giving them an easy way to indicate an attribute of type ID without the overhead of setting up schemas, etc. But there doesn't seem to be any gain in mandating its use in *language design*. Regards, Mark -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Tuesday, 27 June 2006 19:27:12 UTC