groundspeak:cache v 1.1 namespace additions

[iryshe]

For the GPX folks, I have made some additions to the next version of the Groundspeak:cache namespace. This is a request to a) check my work for any glaring errors and offer any final changes before we switch pocket queries to the new version.

 

There are only additions to the namespace, found here:

 

http://www.Groundspeak.com/cache/1/1/cache.xsd

 

Added lastUpdated and exported as optional elements. We will populate lastUpdated but not exported (that one is for external programs to tell how old their data is)

 

GUIDs have been added to all users, caches, cache logs, travel bugs, etc. It is optional and will be the new way at viewing caches in the future. Changes to the database required a change to IDs to GUIDs.

 

We will, however, support the ID fields for viewing caches until the switchover occurs, then continue to support links to those cache pages so there are no linking errors outside Geocaching.com

 

Jeremy Irish

Groundspeak - The Language of Location™

[+ClayJar]

It looks really nice how it is, but as long as the concrete hasn't hardened yet, I may as well ask a few questions about it. (Perhaps these are nits, but they still deserve a few moments.)

 

Okay, I'm dropping the Groundspeak: prefix for brevity of documentation here (so use your imagination). I just have a few questions (or perhaps it's one long question). I'm wondering about the following nodes with maxOccurs="unbounded" (the ones not mentioned make sense to me):

cache/owner: Will a cache really be able to have multiple owners?

cache/attributes: Shouldn't there only be one attributes in which all the attribute nodes are collected?

cache/short_description: Can a cache have more than one short_description?

cache/long_description: Can a cache have more than one long_description?

cache/logs: Shouldn't there only be one logs in which all the log nodes are collected?

cache/logs/log/finder: Will a log be able to have more than one finder?

cache/logs/log/text: Should a log have more than one text block?

cache/logs/log/log_wpt: Will we be able to put more than one log_wpt in a log?

cache/travelbugs: Shouldn't there only be one travelbugs in which all the travelbug nodes are collected?

 

One more little Columbo-ism... Can the XML exporting you're using handle simpleTypes? In other words, can you define in the XSD things like this:

  <xs:simpleType name="logType">    <xs:restriction base="xs:string">      <xs:enumeration value="Found it" />       <xs:enumeration value="Didn't find it" />       <xs:enumeration value="Other" />       <xs:enumeration value="Needs Archived" />       <xs:enumeration value="Unknown" />       <xs:enumeration value="Archive (show)" />       <xs:enumeration value="Archive (no show)" />     </xs:restriction>  </xs:simpleType>

For a log type, size type, cache type, size type, rating type, and so on? That would make life a lot more defined for people coming into the field of GPX apps. If it's too difficult, I can keep the hand updated one I've been using as documentation, but if it were in the XSD, it would be clearer. Not a big deal, since I can keep the separate "sample documentation-only XSD" updated by hand, but if it's not too hard to do, it would be nice to have it as a canonical part of the XSD.

 

[Watcher Downloads] - [Official Geocaching Chat]

[+Lil Devil]

Here's a couple of additional fields I'd like to see:

 

Name of Pocket Query

 

Goal of Travel Bugs

 

Lil Devil

[+fizzymagic]

GUIDs have some advantages for use in the database, and I can understand that. But please don't change the cache IDs to GUIDs. There are several problems with that approach:

• Sorting. You can't sort GUIDs very easily. I suppose you can sort them, but it's a pain.

• Waypoint-to-URL conversion. Won't be possible any more.

• Programming. Nobody but Microsoft likes GUIDs, and they are not first-class objects in any language.

 

It's probably too late, I suppose. Sigh.

[iryshe]

quote:

---

Originally posted by LilDevil:

Name of Pocket Query

Goal of Travel Bugs

---

 

Including the name of the pocket query in the name of the GPX file makes sense. I'll see what we're doing now.

 

Good idea about adding the goal. I'll add that item.

 

quote:

---

Originally posted by fizzymagic:

+ Sorting. You can't sort GUIDs very easily. I suppose you _can_ sort them, but it's a pain.

---

 

Cache ID's are arbitrary anyway. Date sorts make more sense and the cache placement date will still be there. So will the new date fields.

 

quote:

---

+ Waypoint-to-URL conversion. Won't be possible any more.

---

 

Untrue. We'll be adding a search feature by the name of the cache, e.g. GCXXX and TBXXX for geocaches and travel bugs. That feature can be resolved to a URL at Geocaching.com. Right now it does the math and redirects to the right page. It'll probably be something very similar to that.

 

quote:

---

+ Programming. Nobody but Microsoft likes GUIDs, and they are not first-class objects in any language.

---

 

But they are unique nonetheless. Each app will need to implement their own way of storing them internally (if they're stored at all).

 

In short, none of the current functionality will be affected by the change.

 

Jeremy Irish

Groundspeak - The Language of Location™

[+fizzymagic]

quote:

---

Originally posted by Jeremy (Admin):

quote:

---

Originally posted by fizzymagic:

+ Sorting. You can't sort GUIDs very easily. I suppose you _can_ sort them, but it's a pain.

---

 

Cache ID's are arbitrary anyway. Date sorts make more sense and the cache placement date will still be there. So will the new date fields.

---

 

Thanks for the response, Jeremy. Most of what you say is correct. However, there is one way in which cache IDs as currently implemented have a uniquely useful application: they are the only way to tell when caches were submitted and approved.

 

For example, right now if a cacher hides a cache but then waits two weeks to post it, that cache never shows up on the new caches list! In addition, a cacher can arbitrarily change the hidden date of an existing cache to make it show up as a new cache.

 

The way to deal with this issue is to record the submission and/or approval date of each cache, but I didn't see that as part of the proposal. So I guess I am proposing it.

[+parkrrrr]

quote:

---

Originally posted by Jeremy (Admin):

quote:

---

Originally posted by LilDevil:

Name of Pocket Query

Goal of Travel Bugs

---

 

Including the name of the pocket query in the name of the GPX file makes sense. I'll see what we're doing now.

 

Good idea about adding the goal. I'll add that item.

---

 

Another thing that TBs seem to be missing is their URL, though of course one could construct that from the available information.

 

[+MileHighAko]

This is an old thread so I may have missed an update, but whate ever happened with v1.1 of the schema? Pocket Queries is still using version 1.0.

[+Team DEMP]

This is an old thread so I may have missed an update, but whate ever happened with v1.1 of the schema? Pocket Queries is still using version 1.0.

Maybe you ought to check in at http://forums.Groundspeak.com/GC/index.php?showtopic=77082

[Jeremy]

We were going to release 1.1 after we added attributes to caches, but since we haven't (yet) added them, we didn't bother moving to 1.1

 

Since then, GPX has come out with 1.1, so we'll probably add our additional information when we adjust to the new schema. However, as Team DEMP indicated, we're trying to be more proactive by creating a place for application developers to get notified before we implement any new changes.

[+fizzymagic]

Jeremy, can I make a request for the 1.1 namespace? Could we add a <Groundspeak::query_title> item so that we can get the name of the pocket query from the gpx file? Thanks!

[+Allen_L]

I also would like to have query title in the file

[Jeremy]

how about I just use the desc tag?

[Venona]

how about I just use the desc tag?

That would be good way to do it.

Edited August 11, 2004 by Venona

[Jeremy]

Right now it is just filler anyway.

[+fizzymagic]

how about I just use the desc tag?

That would work fine for me, too.

[+Hynr]

I wonder if it might be useful to have a xml tag for URLs to images that are vital to the cache (not the fluff like icons or background images, but the pictures in picture caches or the puzzle images of some puzzle caches). I understand that in the future there would need to be a mechanism for having the cache owner list which images are critical. The cache approver might check to make sure the list does not include fluff.

 

Currently there seems to be no technological way to get critical pictures into PDAs and this would set the stage to have that problem resolved without resorting to including them in the zip files.

[+Maeglin]

I wonder if it might be useful to have a xml tag for URLs to images that are vital to the cache (not the fluff like icons or background images, but the pictures in picture caches or the puzzle images of some puzzle caches). I understand that in the future there would need to be a mechanism for having the cache owner list which images are critical. The cache approver might check to make sure the list does not include fluff.

I'm not sure if GPX 1.0 supported this so much, but GPX 1.1 does support more than one URL associated with a waypoint. Perhaps that could be used for this.