Talk:XML Schema

Discuss the XML Schema page here

---

Pros and Cons

Discussion / pro

• The difference between "Point of Interest", "Waypoint" and "Node" can be expressed through properties. I don't see the need of different data structures. Beside, Point of interests can be parts of the street landscape, as in bus stops, train stations, parking lots etc.
• Same is for streets, bus routes, wander routes etc.
• The scheme of defining areas is common in computer graphic. If there is a better way common in GIS, we should use the better one ;)
• The scheme makes it possible for the server to start the xml-data with the most important data and continue with lesser important data. The client could display only as much data as he wants and then closes the connection and skip the unimportant stuff (as example because the user already clicked on a scroll button).
• I expect the most raised eyebrowns at the fact, that I suggest a seperate list of properties instead of including a tag <properties> in every other object tag. This has several reasons:
  • Properties to other properties will look much cleaner this way.
  • Someone who isn't interested in properties can stop transfering data when he reached the properties - tag. Or a parser could start displaying the data, even when he has not finished receiving the whole dataset. Integrating the properties within the data would make it necessary to

transfer all properties to one object together with it.

• Structure is very simple to parse. The tag's depth is static, the tag names are static. And the whole structure is very strict defined (optional tags makes SAX-parser much harder to write).

contra

• Seperating and cluttering the data of one logical object over several places makes it harder for humans to read the document
• After validating with a parser, you still can't be sure, whether the document is valid. As example it could contain references to id's, not submitted yet. (Question: Can the id-linkage be expressed in XML-Schema?)

Conclusion

• To me, it would be best to support the above XML schema for application reading or writing the key/values. A second GPX interface is not necessary since proxies can be established that translates this to GPX easily.

-- User:Imi - 19:40, 29 November 2005

• • Using "Track" as the name for a collection of segments isn't a good idea. It's confusing because it's too similar to GPX trk notation. Andy's suggestion of "way" would be better, if not "street".
  • I would like to see more respect to the fact that we have collections of nodes and collections of segments - why use XML if you're just going to send flat lists? <nodes> and <segments> would be sensible, with <nodes> coming first so that when a segment refers to an ID it's already been received.
  • Why not just have <street uids="12,13,14,15" /> to represent streets, and have them inherit all the properties of the segments they contain?

- User:TomC- 19:08, 30 November 2005

Can the id-linkage be expressed in XML-Schema? : Yes, the XML Schema key and keyref statements can be used to ensure that the UIDs are unique and the references are valid. I don't think it ensures that the ID's are in the correct order, but you won't have to worry about this if the document is valid! --Matt 16:46, 19 Dec 2005 (GMT))

Inconsistent

In REST you use this to create a segment with properties

<osm version='0.2'>
  <segment tags='name=harrypotter; ; ; ; ; ' from='194797' to='226261' />
</osm>

But if you want to use this schema you would have to do this:

<segment from="85" to="12345" />
<property uid="85" object="19" key="pub" value="cheap beer" />

Why are they different, is this because of SteveC's preference to the semicolon way? This should be consistent with the real world..

-- User:Emj 08:45, 30 November 2005

I always thought Steve's "semicolon way" to be a quick hack implementation until someone fix it up and implement this one. There was a discussion of the disadvantages of the semi-colon stuff somewhere in the mailing list. --Imi 22:02, 20 Dec 2005 (GMT)

XML Schema Description

I made the XML Schema follow the documentation on the article part of this page, apart from a few deviations:

1. I couldn't figure out how to have an element called "nodes" under both the "osm" main element and the "area" element (ditto for the tracks). Instead, I called them "nodeRef" and "trackRef" when under the "area" and "track" elements. This simplifies things a bit, but may not be aesthetically pleasing.
2. There is a bit of additional XML stuff hanging off the "osm" element to do with namespaces. I have to confess, I don't understand XML namespaces at all, so I copied this from another Schema. If someone knows a better way to do it, please step forward!

Additionally, there are a number of points on this page which are worth considering (and probably implementable in XML Schema).

1. Why not have:

<track uid="123">1 2 3 4 5</track>

rather than:

<track uid="123">
  <segmentRef uid="1" />
  <segmentRef uid="2" />
  <segmentRef uid="3" />
  <segmentRef uid="4" />
  <segmentRef uid="5" />
</track>

since Schema is perfectly capable of validating a list of whitespace-separated UIDs. (Note: I don't know whether the XPath/key(ref) stuff can handle it, though...)

1. Ditto above for areas.
2. It may be possible to restrict the references in track and area to point to only UIDs used for segments and nodes, but this is beyond my limited Schema skills!

User:Matt - 18:00, 19 December 2005

Difference between property's "uid" and "object" ?

I see no difference between the attribute "uid" and the attribute "object" of the property tag. Anyone against removing "object" from properties and just use uid? --Imi 22:01, 20 Dec 2005 (GMT)

osmap.org

Hello I just found this website and am very impressed. I've been working on a Map XML based data format for a little over a year, with an end goal similar to OpenStreetMap (I think). Although I still think osmap was a good idea, it hasn't gone anywhere, nobody even knows about it. I'm curious if you would find any parts of osmap useful in the development of yours. Maybe you can get ideas from it while creating your own XML format. Or help develop it and use it as your transfer/sharing format. Or if you think its stupid, maybe I could just point my domain to yours. Check it out at least. http://osmap.org I look forward to helping out or sharing ideas and knowledge. I'm really open to your ideas and opinions, and hope you are too and don't consider this spam!

I read it, at it look not promising to me. Beside the many errors and inconsistencies in the textual definition, it is "just another annotation" scheme for map data. In OSM, annotation stuff is currently seperated from the physical description of the map (which I think is good.) --Imi 14:33, 15 Feb 2006 (GMT)

Way or track

I have checked the referred schema file and in that it is stated that there are no way elements they are called track. I however believe this page is correct. Karlskoging1 22:01, 1 February 2007 (UTC)

Schema Feedback

Hello, I've just been looking at the docs and schema and have some bits of feedback.

• You should plan for versioning in the XSD. Consider having a namespace with a date under it, just as everyone else does. Maybe

 also add a version attribute in the root node so that you can up the version without changing namespace.

• There's nothing in the docs that says whether lat/long are in decimal or alternate representations (remember, its all just strings...this should be explicit). Nor do you say which datum. WGS-84?

• There's no timestamp attribute on node; if there was you'd have to decide between time_t, seconds since 1/1/70, or a full xsd:dateTime format, which appears to be what the example is striving for. But the example is invalid as dateTime is ISO8601 format, and should be something like 2007-03-04T18:15:30Z .

• It's often handy to add an extension point for metadata, say a <metadata> element of type: xsd:any and namespace##other. That tells XSD to only allow stuff in other namespaces (like dublin core or XHTML).

If you must use XSD for your syntax (the good alternate is RelaxNG), consider adding many more sample docs. Ant 1.7 has a special task, <schemavalidate> that is designed to bulk validate a set of docs against some XSD files. So you can have your build process automatically check that the XSD is aligned with your test docs. SteveL 21:06, 15 March 2007 (UTC)