Rich,
Thanks for your comments.
I like the using element name as item name, xsi:type and maxOccurs.
However, I feel
its a bit awkward to specify these in extensions. This would
effectively be adding semantic rules to an <xs:any>.
The spec would have state something like:
- Custom User Profile Items MUST
be
placed in an element which is a child of the extensions field of the
appropriate user profile section.
- The element's local name MUST be
equal to the item's name
- The element MUST have a xsi:type
attribute, the value of which is the element's child's type.
It seems awkward to tie such strong
requirements to a <xs:any> field, particularly extensions which
are intended to be open for implementation details.
Furthermore, if the implementation also sent its own extensions this
could
create a number of problems. The producer would have to determine which
extensions were meant to be customItems and which had another purpose.
Particularly troubling is the case where an true extension's name match
a custom item's name. In which case both could be sent, then producer
would then need to determine how to handle them.
Thanks,
Nate
Thanks for
producing these examples.
In looking at them, I think a couple of things are turned around:
1. the name attribute in the
metadata
should match the element name in the runtime message as this carries
the
semantic information about what the item is;
2. the type information in the
metadata
is for the preparation of serializers/deserializers and should be
carried
at runtime using the xsi:type attribute; and
3. rather than the isArray style of
RPC-encoded, I recommend a maxOccurs attribute like what schema uses
and
perhaps even pushing this attribute down into the schema for the type.
Making these changes results in the
following message formats for the extensions case ... the only
difference
for the customUserItems case is the name of the parent element.
Other changes I would propose (but
did
not include here in order to limit the scope of the next part of the
discussion)
would be broadening the metadata type so that it was not explicit to
customUserProfileItems
(perhaps ExtensionItemDescription), including a ResourceList for
multi-language
versions of the description and possibly a ModelTypes for carrying
schema
information inline.
Rich
|