[OSM-talk] Xml design

[David Earl]

> -----Original Message-----
> From: talk-bounces at openstreetmap.org
> [mailto:talk-bounces at openstreetmap.org]On Behalf Of SteveC
> Sent: 09 January 2007 12:28
> To: scott
> Cc: talk at openstreetmap.org
> Subject: Re: [OSM-talk] Xml design
>
>
> * @ 07/01/07 12:21:01 PM scott at waye.co.uk wrote:
> > Some thoughts:
> >
> > With the current XML design of k="" v="" it would seem very
> difficult to
> > create a useful XSD for the data.  A tight XSD would help to avoid
> > duplication,spelling mistakes, reduce the xml size, and would allow for
> > the gui to present useful drop downs.  For example we currently have
>
> My concern is that if someone wants to invent a tag they just type it
> in, but if we're going to validate then they now have to get involved in
> comittees and standards processes.
>
> Is a good midpoint to have OSM as it currently is, and a processor which
> spits out 'map features compatible' .osm files?
>
> Already the renderers in general ignore broken spellings which has
> helped point out things I've done wrong to me. Is it just this feedback
> loop is a bit weak for bad data?

By coincidence, I've been working on a database recently that has some
similarities to this. I wanted to have a variable schema: different fields
for different record types of course, and only a subset of allowed fields
present in any one record) and for the user to be able to add new fields to
a record type.

As someone said the XML syntax is a distraction: it is the data model that's
the key thing.

Why not have in the database a table of keys allowed for each object type
(node, segment, way, area(?)), and a table of values allowed for those keys
(number, general text, date, etc. and especially enumeration - that is a
list of specific values allowed, such as trunk, primary etc for highway),
and validate the incoming data against these tables.

The editors can then be allowed to modify the tables (they can be delivered
as part of the XML just like the ordinary data and modified in a similar
way, so of course validation can be done locally too), but addition is an
operation which has "more significance" so would appear in a different place
to just adding a key/value pair.

Furthermore, these user-editable tables (in effect a schema) could be
grouped into namespaces (as someone suggested) - a table of namespace, key
name, object type to tie them together or some such. Then you can have
key/values for particular purposes (e.g. osmarender:nameDirection,
archaeology:romanexcavation) qualified by namespace.

This way, we get the validation, but also the user extensibility, without
having to learn much new (and is still specific to your chosen editor rtaher
than about standards).

The XML DTD can be derived *dynamically* from the database variable schema
if a DTD is wanted and the key/value structure is to use the actual key
names highway='trunk' rather than k='highway' v='trunk'. (Remembers the DTD
is a link, so whatever it provides can be generated rather than just
stored).

David