|
From: Graham C. <g+o...@co...> - 2011-01-20 14:50:09
|
On Wednesday 19 January 2011 02:12:31 Chris Frey wrote: > On Tue, Jan 18, 2011 at 02:49:20PM -0800, Emanoil Kotsev wrote: > > GEO:48.150002\;17.116667 > > There appears to be a problem with this line. If you remove the > escape backslash, then it should work. > > Otherwise, the full string is taken as the Latitude (48.150002;17.116667) > and there is no Longitude, and the XMLFormat validation rightly > complains. Experience teaches us that implementation of the V-formats in the real world is very poor! It would be worth both the vformat and xmlformat code in OpenSync to be more tolerant. OpenSync is in the business of syncing user's devices, not enforcing minor standards violations. As this particular bad encoding has now been seen in the real world we can assume it will be seen again. It seems like the vformat code could, and should, handle it, as a variant and parse the GEO: with the \; as well as the correct version without the \. However, in any case, it should also make sure it **always** generates valid XML (or none at all). So, GEO:xxx should generate either no <Location> or a valid one. There may also be a case that the xmlformat code should just be dropping badly formatted fields although, as a purely internal format, I can see the justification for aborting, but only if the code which creates the XML is capable enough to always generate either no field or a correctly formatted field. Graham |