[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Problem defining Relationship XML
Hi Zhili,
You're
right that simply turning the "role" attribute into an element isn't enough, it
also needs to be moved to 3rd position. But I don't see that as being much of a
problem.
Seems
to me, the reason we have this problem is that we want to explicitly list two
optional element that we don't need. Because of the xsd:any that comes after,
the set of valid elements described by the schema is exactly unchanged if we
remove the ResourceId and ManageabilityEndpointReference. These belong in the
text of the spec (we should tell people that they should put these elements) but
there really is no reason to list them explicitly in the schema. But I think I
remember having this discussion once and I wasn't able to convince people who
wanted to see ResourceId and ManageabilityEndpointReference in the schema. Do I
remember correctly?
The
wrapper you suggest would work too, but I don't see what justifies this added
layer versus just moving role to 3rd position (assuming we still keep ResourceId
and ManageabilityEndpointReference).
Thanks,
William
From: Zhili Zhang [mailto:zhili@tibco.com] Sent: Tuesday, November 23, 2004 11:01 AM To: Vambenepe, William N; Murray, Bryan P.; fred.carter@amberpoint.com Cc: wsdm@lists.oasis-open.org Subject: RE: [wsdm] Problem defining Relationship XML I donot think making "role" an
element will solve the problem. The problem is because ''muws-p1-xs:ResourceId'
is optional and from another namespace. The name matches both the optional
particle and the following wildcard, which violates "Unique Particle
Attribution" rule.
The
following options fix the schema error:
(1) Make MUWS part1 and part2 in the same namespace, as suggested by Igor, and Fred. If this is not possible, then
(2) Introduce a wrapper element wraps elements "ManageabilityEndpointReference" and "ResourceId". These two perhaps are the most commonly used identifiers for a participant. Putting them in an element and separating from other "unknown" identifier types does not make things worse. I don't have a good name for the wrapping element yet. <complexType name =
"RelationshipParticipantType">
<xs:sequence> <xs:element name="Role" type="xs:anyURI"/> <xs:element name = "Wrapper" minOccurs='0'> <complexType> <sequence> <element ref = "muws-p1-xs:ManageabilityEndpointReference" minOccurs = "0" maxOccurs = "unbounded"/> <element ref = "muws-p1-xs:ResourceId" minOccurs = "0"/> </sequence> </complexType> </xs:element> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:anyAttribute namespace="##other"/> </complexType> (3) Rearrange the order of elements in the sequence. One possible way is to move "Role" to the third element (before "any"): <complexType name =
"RelationshipParticipantType">
<xs:sequence> <xs:element ref="muws-p1-xs:ManageabilityEndpointReference" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="muws-p1-xs:ResourceId" minOccurs="0"/> <xs:element name="Role" type="xs:anyURI"/> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##other" processContents="lax"/> </xs:sequence> <xs:anyAttribute namespace="##other"/> </complexType> This one doesn't look pleasant. It does correct the schema error
though.
There is no perfect solution at this time. But this issue has to be
resolved.
Thanks
Zhili Zhang TIBCO Software Inc.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]