[OSM-talk] Xml design

[Nigel Magnay]

Regardless of the XML output format (which is just a transformation),
tags ought to be able to be namespaced in a way that allows easy
identification of tags that "should" be consistent. This would allow
both the identification of mistakes and maintain the 'freeform'
tagging flexibility that we currently have.

So I could say
<tag ns="osm1.0" k="highway" v="unclassified" />

and
<tag ns="nigelmtags" k="rambling" v="excellent"/>

If you want to "validate" the output in some way (which I'm not sure
it ever can be invalid if the tags are always freeform), then you
could use something like schematron rather than XSD (which is really
only designed to validate structure anyway, and is horribly horribly
broken) or perhaps RelaxNG. There's also nothing stopping you XSLTing
out particular tag vocabularies into something more easily passed
through a schema. I suspect though that trying to run planet.osm
through a schema validator, you'll be here until the heat-death of the
universe... ;-))


On 07/01/07, scott <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
>
>   <way id="4073353" timestamp="2006-12-13T01:57:16+00:00">
>     <seg id="65667" />
>     <seg id="65652" />
>     <tag k="created_by" v="JOSM" />
>     <tag k="highway" v="unclassified" />
>     <tag k="oneway" v="true" />
>   </way>
>
> What I am proposing is to have
>
>   <way id="4073353" timestamp="2006-12-13T01:57:16+00:00"
> created_by="JOSM" highway="unclassified oneway="true">
>     <seg id="65667" />
>     <seg id="65652" />
>   </way>
>
> We could then have an XSD which lists the valid values for the highway
> attribute, and applications like JOSM could present those in a drop
> down.  Presently, for example, in the database we have the following
> attributes:
>
> abbutter
> abbutters
> abutment
> abutters
> abuttors
>
> we also have at least 10 versions (these are just the ones that begin
> with h) of highway:
>
> hgihway
> hifgway
> highawy
> highjway
> highwau
> highway
> highway:
> highwy
> higway
> hoghway
>
>
>
>
>
> The argument might be put forward that the current design allows more
> flexibility.  But I dont buy that.  There is nothing to stop you
> extending the XSD when needed.  That is what the X stands for,
> extensibility.
>
> I dont care if they are stored in the SQL database as name value pairs,
> thats a different issue, and the current implementation is fine as far
> as I'm concerned.
>
> Any thoughts?
>
> --
> Scott
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>