W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > May 1997

RE: SD5 - Namespaces - New Version 2

From: Tim Bray <tbray@textuality.com>
Date: Mon, 26 May 1997 15:03:09 -0700
Message-Id: <3.0.32.19970526150301.01089d10@pop.intergate.bc.ca>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:26 UTC