[OSM-talk] Xml design

Scott scott at waye.co.uk
Mon Jan 8 09:15:35 GMT 2007



On 1/7/2007, "Nigel Magnay" <nigel.magnay at gmail.com> wrote:

>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"/>

You dont need to have a new namespace for this xsd:any would suffice.
(http://www.w3.org/TR/xmlschema-0/#any)

Anyway the issue is the misspelling which namespaces alone will not solve.


>
>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... ;-))

I'm am not trying to validate, but am trying to use the data in a route
planner.  I just want to pick the highway tags, but I cannot as they
have different names.  I will have similar problems in calculating costs
based on highway type, and junctions.

>
>
>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
>>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk




More information about the talk mailing list