- From: Tim Bray <tbray@textuality.com>
- Date: Mon, 26 May 1997 15:03:09 -0700
- To: w3c-sgml-wg@w3.org
At 02:47 PM 5/26/97 -0700, Andrew Layman wrote: >Paul Grosso asks whether it makes sense to have the namespace of an >attribute be anything other than the namespace of its containing >element?... >Does it make sense to have a CURRENCY attribute that is defined in a >namespace that is not PRICE? Absolutely. Having a single meaning and >representation of currency used across a wide range of applications is >valuable. We are running significant amounts of risk in rushing into this namespace extension stuff. Nevertheless, we accept that this is urgent. Given the risk (of doing something stupid with horrid downstream consequences), it is clearly good to introduce the minimal amount of machinery necessary to achieve the desired effect. Let us consider the following dogma: For namespace purposes, the unit of import and scoping is the element. Clearly, in all the examples we've seen so far, the desired goal could be achieved with imported element constructs. Given that this principle reduces the amount of machinery we have to build, with an attendent associated risk reduction, the onus is on those who want to extend this to attributes to prove the necessity for so doing. >Documents, and database records, and e-commerce transactions >and a variety of other applications could then all have a common >representation of CURRENCY, drawn from a single namespace. Right. And imported as an element. Doesn't break any of the examples. Furthermore, the supposition in the example, that in a real-world international financial transaction, price can be decoupled from currency, is amusingly naive. - Tim
Received on Monday, 26 May 1997 18:04:51 UTC