[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] Problem defining Relationship XML
First of all, why is xs:any namespace="##other" ?? why
can't that thing include elements from the MUWS namespace itself? I believe
unless explicitly prohibited for a reason, namespace should be
##any.
I also
belieeve that there is no need to include those optional elements in the schema.
The only reason to do so is to make sure the order or their appearance is set by
the spec. That may be the only reason.
BTW, I
just ran this p2 schema through the .NET XSD compiler and it looks just fine.
Here is C# code for the RelationshipParticipantType
///
<remarks/>
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/wd-wsdm-muws-part2-1.0.xsd")] [System.Xml.Serialization.XmlRootAttribute("Participant", Namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/wd-wsdm-muws-part2-1.0.xsd", IsNullable=false)] public class RelationshipParticipantType { /// <remarks/> [System.Xml.Serialization.XmlElementAttribute(DataType="anyURI")] public string Role; /// <remarks/> [System.Xml.Serialization.XmlElementAttribute("ManageabilityEndpointReference", Namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/wd-wsdm-muws-part1-1.0.xsd")] public EndpointReferenceType[] ManageabilityEndpointReference; /// <remarks/> [System.Xml.Serialization.XmlElementAttribute(Namespace="http://docs.oasis-open.org/wsdm/2004/12/muws/wd-wsdm-muws-part1-1.0.xsd", DataType="anyURI")] public string ResourceId; /// <remarks/> [System.Xml.Serialization.XmlAnyElementAttribute()] public System.Xml.XmlElement[] Any; /// <remarks/> [System.Xml.Serialization.XmlAnyAttributeAttribute()] public System.Xml.XmlAttribute[] AnyAttr; } -- Igor
Sedukhin
..
(igor.sedukhin@ca.com) From: Vambenepe, William N [mailto:vbp@hp.com] Sent: Tuesday, November 23, 2004 2:20 PM To: Zhili Zhang; Murray, Bryan P.; fred.carter@amberpoint.com Cc: wsdm@lists.oasis-open.org 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]