[
Lists Home |
Date Index |
Thread Index
]
Roger L. Costello wrote:
> This is quite a radical approach. I am surprised that there
> aren't more comments, since the "conventional wisdom" is
> not to treat kilometer as a property/relation/function, but rather
> to treat it as the value of a property, e.g.,
>
> <River id="Yangtze">
> <length unit="kilometer">6300</length>
> </River>
The advantage of "<kilometres>6300</kilometres>" as opposed to <length
unit="kilometre"> is in modularity of type definition.
With the unit= approach, you're probably saying that the type of length
is an attribute that can be km/miles/nautical miles/etc, and a value
which is a number.
However, if you want to allow other types of length measurement - non
numerical ones such as giving the name of another object of the same
length, say - then with the latter approach your 'type' might need to
widen to include any value as the distance, not expressing the fact that
for kilometres it'd better be a number, while if you have a
"<kilometres>" element then you can state that it contains an integer
while a "<same-as>" element contains a string.
However, smarter type systems let you define types in terms of things
like "distances where unit='kilometres'" and thus allow you to organise
it however you want, so it becomes a moot point.
I find "unit=''" more pleasing on the eye, myself.
> Thoughts? /Roger
ABS
|
