OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[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.
-----Original Message-----
From: Vambenepe, William N [mailto:vbp@hp.com]
Sent: Sunday, November 21, 2004 3:14 PM
To: Murray, Bryan P.; fred.carter@amberpoint.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Problem defining Relationship XML

Let's just make "role" an element rather than an attribute and this will take care of it.
 
William


From: Murray, Bryan P.
Sent: Friday, November 19, 2004 5:16 PM
To: fred.carter@amberpoint.com
Cc: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Problem defining Relationship XML

I was using xsd.exe from MS .NET Framework 1.1.
 
The error is:
 
Schema validation warning: The content model must be deterministic. Wildcard declaration along with a local element declaration causes the content model to become ambiguous. An error occurred at .../wd-wsdm-muws-part2-1.0.xsd, (124, 4).
 
The message isn't very clear but I played around with it until I discovered the problem I reported.
 
Bryan


From: Fred Carter [mailto:fred.carter@amberpoint.com]
Sent: Friday, November 19, 2004 5:09 PM
To: Murray, Bryan P.
Cc: wsdm@lists.oasis-open.org
Subject: Re: [wsdm] Problem defining Relationship XML

Thus quoth Murray, Bryan P. (~ 11/19/2004 4:47 PM ~)...
I am having a problem defining a schema for Relationship that validates.
The pseudo-schema for Relationship (from MUWS part2) is the following:

<muws-p2-xs:Relationship>
  <muws-p2-xs:Name>xs:string</muws-p2-xs:Name> ?
  <muws-p2-xs:Type>muws-xs:RelationshipType</muws-p2-xs:Type>
  <muws-p2-xs:Participant Role="xs:anyURI">
    <muws-p1-xs:ManageabilityEndpointReference/> *
    <muws-p1-xs:ResourceID/> ?
    {any}*
  </muws-p2-xs:Participant>
  <muws-p2-xs:Participant/>+
  <muws-p2-xs:AccessEndpointReference>
    wsa:EndpointReferenceType
  </muws-p2-xs:AccessEndpointReference>?
  {any}*
</muws-p2-xs:Relationship>



The problem I have run into is in defining the ParticipantType
complexType. I have tried the following:

  <xs: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:any minOccurs="0" maxOccurs="unbounded"
              namespace="##other" processContents="lax"/>
    </xs:sequence>
    <xs:attribute name="Role" type="xs:anyURI" use="required"/>
    <xs:anyAttribute namespace="##other"/>
  </xs:complexType>

The error I am getting is that the 'any' is causing ambiguity because
there are no required elements - and all optional elements are from the
part1 namespace. All I need is a required element in any namespace to
make it validate.

Does anyone have any suggestions?
  
A better schema processor?

When I attempt to validate the following with XmlSpy (v2005)
  <?xml version="1.0" encoding="UTF-8"?>
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:muws-p1-xs="urn:bar" targetNamespace="urn:bar">
	<xs:element name="foo">
		<xs:annotation>
			<xs:documentation>Comment describing your root element</xs:documentation>
		</xs:annotation>
	</xs:element>
	<xs:element name="ManageabilityEndpointReference"/>
	<xs:element name="ResourceId"/>
	<xs: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:any minOccurs="0" maxOccurs="unbounded"
              namespace="##other" processContents="lax"/>
    </xs:sequence>
    <xs:attribute name="Role" type="xs:anyURI" use="required"/>
    <xs:anyAttribute namespace="##other"/>
   </xs:complexType>
  </xs:schema>

I had no problem.  When I change the ##other (highlighted in red) to ##nay, it complained that that would make things non-deterministic.  Which makes sense...

I know this isn't much help, but I think it means you're right and that ?+*&%#$ schema processor leaves a bit to be desired...

/fred

Bryan

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.


  


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]