Schema validity error for element 'Location'

[tuju]

element Location: Schemas validity error : Element 'Location': Missing child element(s). Expected is ( Longitude ).

libopensync-0.32-0.fc6.2487svn
libopensync-devel-0.32-0.fc6.2487svn
libopensync-plugin-file-0.32-0.fc6.2487svn
libopensync-plugin-kdepim-0.32-0.fc6.2487svn
libopensync-plugin-syncml-0.32-0.fc6.2487svn
libopensync-plugin-vformat-0.32-0.fc6.2487svn
libsyncml-0.4.4-0.fc6.246svn
libsyncml-devel-0.4.4-0.fc6.246svn
msynctool-0.32-0.fc6.319svn

[dgollub]

I guess the validation errors is about a wrong converted vcalendar/icalendar.

[tuju]

Still valid ticket for 0.33 r2599

[cstender]

Tuju, can you please attach the vevent which cause this conflict?

[tuju]

sent traces + capabilites file in email to cstender.

[felixmoeller]

 http://opensync.org/browser/trunk/misc/schemas/xmlformat-contact.xsd contains the following, which should cause this issue.

    <xsd:complexType name="Location">
      <xsd:sequence>
        <xsd:element minOccurs="1" name="Latitude" type="xsd:string"/>
        <xsd:element minOccurs="1" name="Longitude" type="xsd:string"/>
     </xsd:sequence>
    </xsd:complexType>

[cstender]

The problem seems to be a wrong handled GEO attribute:

e.g. GEO:0.000000\;25.664989

<Location>

<Latitude>0.000000;25.664989</Latitude>

</Location>

From vcard-21.doc spec:

This property specifies information related to the global positioning of the
vCard object. The property specifies a longitude and latitude. The latitude
represents the location north and south of the equator as a positive or
negative number, respectively. The longitude represents the location east
and west of the prime meridian as a positive or negative number, respectively.
The rationale behind providing support for this property is that it
is relatively simple for a vCard object to provide this information compared
with how difficult it would be for a receiver of a vCard to determine the
global location through some other means.
This property is identified by the property name GEO. An example of this
property follows:
GEO:37.24,-17.87
Support for this property is optional for vCard Writers conforming to this
specification.

[tuju]

So code that creates xml does not add the longitude like the error says.

[cstender]

well, the code seems to be correct. I guess this bug is location in our vcard parser.

[cstender]

s/location/located/

[cstender]

The problem is the backslash in GEO:0.000000\;25.664989. Without it everything works fine for me. I'm not sure what we can do here. Where is the contact from? Nokia cellphone?

[tuju]

yep, i use s60/s80 phones and kdepim. but can't remember where that came in the first place. has it been injected by osync features or could it appear in fresh environment.

is that backslash against standards?

[cstender]

   Type value: A single structured value consisting of two float values
   separated by the SEMI-COLON character (ASCII decimal 59).

   Type special notes: This type specifies information related to the
   global position of the object associated with the vCard. The value
   specifies latitude and longitude, in that order (i.e., "LAT LON"
   ordering). The longitude represents the location east and west of the
   prime meridian as a positive or negative real number, respectively.
   The latitude represents the location north and south of the equator
   as a positive or negative real number, respectively. The longitude
   and latitude values MUST be specified as decimal degrees and should
   be specified to six decimal places. This will allow for granularity
   within a meter of the geographical position. The text components are
   separated by the SEMI-COLON character (ASCII decimal 59). The simple
   formula for converting degrees-minutes-seconds into decimal degrees
   is:

        decimal = degrees + minutes/60 + seconds/3600.

So yes, I guess it is not valid.

[cstender]

Maybe this vcard was generated by vformat which had a bug with newlines. Can I close this as invalid for now?

[tuju]

Maybe this vcard was generated by vformat which had a bug with newlines.

Could be. I'll reopen it if it still persists.

Can I close this as invalid for now?

Well, if it was caused by 'vformat which had a bug', then it should be closed with FIXED, right? :)

[cstender]

Yes, you're right. Please try to reproduce. Thanks a lot!

[cstender]

Hmm, maybe I should wait for your feedback and then close this bug as fixed. :)

[cstender]

Tested it again. Works for me without changing code. If you can find a wrong encoded location attribute please open a new bug.