[OSM-dev] Restrict key names on order to retain reusability of OSM

[Stefan Keller]

You are right that XML names (= keys/tags) are valid in unicode
in which case the encoding of the whole XML document (exchange file)
must support this.

But you know well that many tools have problems with non-ASCII XML
element and attribute names (for content/value UTF-8 is ok since
chars can escaped)!

So, my last 20cents for valid key names before I give up is the following:
'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ_-.0123456789'
whereas such qualified names must begin with a letter and contain at
most one colon and have at most a length of 255.

I'm happy to see from the existing OSM data that users seem to be
more prudent than some of you which is weird since usually it's the
other way round (look e.g. why we two insert a line feed after 70 chars
way before the end of paragraph) ;-> Just think about it.

Stefan
P.S. Local social bookmark services exist - but mainly because of the
success of the big (ASCII-based) ones.

2008/2/12, Dave Stubbs <osm.list at randomjunk.co.uk>:

> On Feb 12, 2008 1:27 PM, Stefan Keller <sfkeller at gmail.com> wrote:
> > Thanks for the pointer o XML, Dave.
> >
> > UTF-8 is a good choice for content, but this is about *keys* (i.e.
> > attributes).
> > Keys correspond to XML elements which are defind as names [1](!)
> > ... which nicely fits the definition I proposed.
>
>
> Well, my point was that your proposal was a very small subset of what
> XML allows for a Name, so no, it really doesn't nicely fit.
> Just to clarify that, XML allows pretty much anything except
> whitespace and most punctuation to be part of a Name. This includes
> just about any UTF-8 character you wish to bring up. There are lots of
> other rules and limitations of course, but that's what the grammar on
> that page is there to describe, so I won't try to summarise it further
> here.
>
> There's nothing special about an OSM key. It's the same as an OSM
> value contents-wise and should really be treated as such by any
> application processing it. This actually makes a lot of programming
> easier, not harder.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080212/6408035a/attachment.html>