[dsdl-discuss] Re: Numbers and units

 From: "Eric van der Vlist" <vdv@dyomedea.com>
 
> Might be, OTH even so, a formal description of the relations between the
> units would be computable by the validators which would be able for
> instance to deduce the relation between square inches and square
> millimeters from the relationc between inches and centimers and the
> relation between centimeters and millimeters.

It is already more complex than Martin was suggesting! I think it
is fair enough to have a schema language that supports scientific
documents, but that is the realm of MathML and not something that
I think we have a requirement for.
 
> What I don't like about using attributes for the units is that it's not
> extensible and that you can't "qualify" the unit.

It is completely extensible, because new units can be defined and
related to a canonical unit.

> > My approach is based on the criteria that we need to support the
> > kinds of attribute values (and data values) actually found in real
> > markup languages in the publishing area. There is no requirement
> > from that for a "universal solution" AFAIK.
>
> I have very mixed feelings about this sort of arguments :-)

The only mechanisms I know of for creating requirements are:
  1) use-cases
  2) expertise/intuition
  3) tossing coins
  4) copying what everyone else has already done.

I do not believe we should do 2 or 3. I do not believe that 4 (e.g. using
the ISO standard datatypes) will provide any value for people making
documents: indeed, XML Schemas already includes these, so we would
be reinventing the wheel. In any case, the ISO datatypes are based on
storage constraints and so are positively the wrong direction IMHO anyway,
unless we want to support multiple sets of primitives. (Do we?)

But I recognize that requirements exist in the domain of the possible, and
figuring out what is possible can alter the selection of requirements.

> On one hand, I agree that we shouldn't try to solve issues which don't
> exist in the real world, OTH it's by using this kind of arguments again
> and again that W3C has produced such a mess with W3C XML Schema.

Well, from my POV XML Schemas went right when it *did* follow
concrete requirements: for example, the Java and database people like
XML Schemas because it supports programming and database types.

The "mess" of XML Schemas comes from poor architecture, spurious claims
of universality, horrible writing, bad systems design (PSVI), the introduction
of niche requirements such as nil to a supposed general-purpose language,
incomplete specificitions (such as keys and dates),

Modularity should give us a better architecture. Meeting publishing's needs
first gives us better focus. RELAX NG nice example and ISO's rules
will hopefully give us better writing. We don't have a PSVI. We don't
need to be a kitchen sink, with everything piled in. We can learn from
the mistakes of XML Schemas for keys and dates.

> If we can define a mechanism to better define what "numbers" and "units"
> are, if this mechanism doesn't add that much complexity and if it's
> based on existing technologies I think that it's something we should try
> to look at especially when we are in "brainstorming mode" like we are now!

Sure. But we each need to make clear what the industrial problem we (i.e. our
national bodies, etc) need to solve. If we want to support DBMS exchanges
or international banking, that is fine, but it needs to be explicitly stated. Datatyping
is such a big area that unless we have targets we will waste our time, and not
provide any viable alternative to W3C.

What concrete problem are you trying to solve?

One feature of my approach is that precision is completely left to implementations,
and only single-stage conversions to a canonical value are allowed: this can
allow high precision and reduce the chances of accumulated error.
This is one reason I don't want to build-in any knowledge of particular units
(e.g. what is a month) or relationships (i.e. inches to cm).

Cheers
Rick Jelliffe

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)