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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dsml message

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


Subject: Re: [dsml] Extensibility for enumerations


Using XSV, today I was able to prove the memberTypes attribute on a union will produce the desired behavior.  With the memberTypes attribute omitted, the values in the instance document are restricted to the enumerated values.  With it, the values can be whatever they want to be within the specified member types.  That satisfies extensibility for enumerations and we would suggest that as a definite change to be included in a DSML v2.1.  Also, is has become our opinion that any <xsd:choice> should include an <xsd:any ...> clause for extensibility.  Other items are already extensible through the <xsd:extension ...> mechanism.  However, we're still looking at it, but our other extensibility concerns apparently would require a more drastic structural change to the DSML v2 specification.  The best example would still be the DsmlModification example heretofore laid out.
 
Tom Doman
tdoman@novell.com

>>> "Tom Doman" <TDoman@novell.com> 4/3/2003 10:37:00 AM >>>
Hello Ed and welcome.  Yes, you're the guy I was referring to.  I have XSV but haven't used it on our xsd's yet since they're still in a lot of flux.  I had, perhaps incorrectly, assumed that a validator would only check instance documents against a given schema but, now that you mention it, I suppose it would have to first validate the xsd to make sure it doesn't violate the XML Schema recommendation.  I'll try it out on our more uncertain constructs.
 
Thanks,
Tom

>>> "Ed Day" <eday@obj-sys.com> 4/3/2003 8:52:39 AM >>>
Hello,
 
I believe I am the person at Objective Systems to whom you refer and I have indeed now joined the group.  The way you show the extended enumeration type below is the way we were thinking of doing it was well and I believe this should work.  As far as free XML structure checkers (or validators are they are more commonly known), I can suggest the following links:
 
Xerces Java validator can be downloaded from:
http://xml.apache.org/xerces2-j/index.html

IBM Xml Schema validator can be downloaded from:
http://www.alphaworks.ibm.com/tech/xmlsqc

XSV Schema Validator can be found at:
http://www.w3.org/2001/03/webdata/xsv
We have checked all code we have done to date with these and the conversions are showing no errors.
 
Regards,
 
Ed Day
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
mailto:eday@obj-sys.com
http://www.obj-sys.com
 
 
----- Original Message -----
From: Tom Doman
Sent: Wednesday, April 02, 2003 8:13 PM
Subject: [dsml] Extensibility for enumerations

We have been corresponding with an individual at Objective Systems who is working on the ASN.1 to XML Schema conversion tool we discussed in the last conference call.  I believe he may have joined the DSML group now too.  We discussed the extensibility of enumerations in XML Schema and he said that through the use of xsd:union and the memberTypes attribute this could be done.  As far as I understand it, he said that the use of the memberTypes attribute would render the xsd:restrictions listed in the xsd:enumerations as the "known" values at the time but they would not limited to those.  It sounds reasonable to us but, as I think is well documented here, we are no XML Schema experts.  Can anyone corroborate this?  Also, can anyone suggest a good free XML Schema structure checker?
If this is correct, going back to the DsmlModification from DSML v.2, a 2.1 implementation might look something like this:
 
 <xsd:complexType name="DsmlModification">
  <xsd:sequence>
   <xsd:element name="value" type="DsmlValue" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
  <xsd:attribute name="name" type="AttributeDescriptionValue" use="required"/>
  <xsd:attribute name="operation" use="required">
   <xsd:union memberTypes="xsd:string">
    <xsd:simpleType>
     <xsd:restriction base="xsd:string">
      <xsd:enumeration value="add"/>
      <xsd:enumeration value="delete"/>
      <xsd:enumeration value="replace"/>
     </xsd:restriction>
    </xsd:simpleType>
   </xsd:union>
  </xsd:attribute>
 </xsd:complexType>
This, of course, doesn't solve the association of the operation types with different "value" types as did my earlier example but it would allow additional xsd:strings to be specified as the operation.  If this construct achieves extensibility for enumerations then XML attributes aren't as restrictive as we thought and this would address some of the problems we had with the 2.0 specification.  Comment?  Questions?  Insights?
 
Thanks,
Tom Doman
 


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