[Openstreetmap-dev] OSM's Schema - moving it forwards.

[Immanuel Scholz]

Hi,

it seems, that it could be wise to explain again why I am such against
the additional tags in the schema (btw: I am against a "tags" tag
too ;).


> > Please, can you explain WHY you want to have specific tags instead of
> > the general way of specifying attributes?

> I think there are fundamental properties that occur in almost all cases and it 
> simply makes sense to have them as attributes in the schema.

I fully agree, that some attributes are really general and likely to be
common in most languages, countries and usage scenarios of OSM. name is
a very good example for this.

But I fail to see this as a reason to add tags for them.


> The trouble with no standard attributes is clients will never know exactly 
> what to expect.

Sorry, but this is just wrong. A client can just read the
"...;name=foobar;..." from a "tags" tag or read the "<property ...
key="name" />" from the xml to get names. It is no better or worse than
an optional "name"-tag.

There is no difference of the client in believing that the tag
"name" (if present) hold the name of the object than believing that the
value to the key "name" (if present) hold its name.


And it will be exactly the same for the server either. The server would
translate a "<... name="foobar"... />" just into the property "name" for
internal store and retranslate it back to the tag when delivering the
data.


> I believe one of the Birmingham guys is drawing up such a schema and
> it would be good to reach a consensus based on this.

It is always good to have some definition of what keys should be used by
clients and how they are spelled.

However, I don't like them to be in the XML-Schema.


There is another serious problem. I consider this the main disadvantage:
It is more complex and inperformant to specify some optional data
directly as tags. This is because:

- Clients have to read the attribute data before continue reading the
other map data. This makes it slower for clients which incrementally
draw the map while fetching data.
- This will lead to a complex scheme of server based filtering requests
to strip data of the request. I predict, that server requests will be
necessary where these tags are stripped to fast gain any map information
without the additional data. E.g. this will lead to something like
"map?...&strip=name,class".
- Parser get harder to write
- The more complex parsers need to be changed every now and then when
the schema changes.
- The gain in simplicity is only for humans. The xml is NOT to be read
by humans. IF it is desired to read the xml manually, a small piece of
script code can turn the xml to a much more human readible form.


Ciao, Imi.