Questions about capabilities - again

[Henrik /KaarPoSoft-2]

I am not sure if this ever reached the list.
Apologies if you get it twice

1)
In capabilities.xsd we have an element called Parameter with
maxOccurs="unbounded".
In opensync_capability.h/c we have osync_capability_set_parameter whichs
sets ONE parameter.
As far as I can see, it sould be possible to have several parameters (such
as both Location and Pref for an Address).
So: is this a bug in the capabilities API (i.e. opensync_capability.h/c)?

2)
A well-formed XML document must have exactly one root node.
According to capabilities.xsd the root node must be <Caps> which has an
attribute called CapsFormat.
If a plugin is offering capabilities in different CapsFormats (e.g.
because it supports both vformat and xmlformat), how would this be
specified?
Suggestion: Rename <ObjType> to <ObjTypeCaps> and move the CapsFormat
attribute from <Caps> to <ObjTypeCaps>.
(API change probably needed as well).

3)
capabilities.xsd defines that <Cap> can have a <DisplayName> child, and
that <Parameter> can have a <DisplayName> child.
When would we ever want to show an end-user the name of a capability or
parameter?

4)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child, but no
<MinOccurs> child.
Is this a mistake, or is it because the demerger would not be able to
handle it anyway (i.e. what should the merger do if the change does not
include the attribute for which MinOccurs > 0 ? )

5)
capabilities.xsd defines that <Cap> can have a <Type> child, and that
<Parameter> can have a <Type> child.
What is the purpose of this?
I would expect that the type is defined by the format-plugin.

6)
capabilities.xsd defines that <Cap> can have <Min> and <Max> children.
I would like an example of how this would be used.
I.e.: Are there any conceivable format elements which have an unrestricted
range, or say a range of A-B, but where a plugin/member would only be able
to handle part of this range?

7)
capabilities.xsd defines that <Cap> can have a <MaxOccurs> child.
Do we really expect demergers to handle this?

8)
The current logic in _osync_obj_engine_mapping_find is:
Clone (i.e. make a complete copy of) change1. Demerge fields from the
clone which are not in caps2.
Clone (i.e. make a complete copy of) change2. Demerge fields from the
clone which are not in caps1.
Compare the two cloned objects.
To me this seems unnecessarily complicated and incurs a performance penalty.
Why is this not implemented as a more "intelligent" compare function,
which takes capabilities into account?

/Henrik




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel