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] | [Elist Home]


Subject: Re: DsmlValue


From what I've been able to digest (still a lot of indigestion going on) from the schema spec, it should probably be defined as:

 <xsd:simpleType name="DSMLValue">
  <xsd:union memberTypes="xsd:string xsd:base64Binary xsd:anyURI"/>
 </xsd:simpleType>

The schema processor would first try to evaluate as string, and since anything evaluates as valid string, the type would be considered to be string. Using xsi:type can be used to force evaluation as one of the other types in the union, but would not be considered valid if a type not in the union is specified. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#atomic-vs-list, particularly section topic 2.5.1.3)

If we don't want to rely on xsi:type, but our own valuetype attribute, it would have to look something more like:

 <xsd:simpleType name="DSMLValueType">
  <xsd:union memberTypes="xsd:string xsd:base64Binary xsd:anyURI"/>
 </xsd:simpleType>

 <xsd:simpleType name="DSMLValueEnum">
   <xsd:restriction base="xsd:string">
     <xsd:enumeration value="string"/>
     <xsd:enumeration value="base64Binary "/>
     <xsd:enumeration value="anyURI"/>
   </xsd:restriction>
 </xsd:simpleType>

 <xsd:complexType name="DsmlValue">
   <xsd:simpleContent>
     <xsd:extension base="DSMLValueType">
       <xsd:attribute name="valuetype" type="DSMLValueEnum" default="string"/>
     </xsd:extension>
   </xsd:simpleContent>
  </xsd:complexType>



Shon Vella
Software Engineer, Consultant
svella@novell.com
Novell, Inc., the leading provider of Net services software
www.novell.com 

>>> Shon Vella <SVELLA@novell.com> 09/19/01 10:01AM >>>
I would also propose adding a default value of xsd:string for valuetype, eg:

<!-- **** DSML Value **** -->

 <xsd:simpleType name="DSMLValueType">
  <xsd:union memberTypes="xsd:string xsd:base64Binary xsd:anyURI"/>
 </xsd:simpleType>

 <xsd:complexType name="DsmlValue">
  <xsd:attribute name="valuetype" type="DSMLValueType" default="xsd:string"/>
 </xsd:complexType>

Another issue is that it would seem to require the instance document to declare the schema namespace, and would require the client server to treat valuetype as a QName even though it isn't explicitly typed as such (though it could be). Since it isn't xsi:type it won't be used for schema validation, so I'm not sure what value it adds to have these be QNames rather just an enumeration of values that are mapped to the schema types.

Shon Vella
Software Engineer, Consultant
svella@novell.com 
Novell, Inc., the leading provider of Net services software
www.novell.com 

>>> Christine Tomlinson <chris.tomlinson@sun.com> 09/19/01 09:48AM >>>
Both Jeff and Shon have pointed out the poor characteristics of the Sun proposal w.r.t. DsmlValue.

In the spirit of the observations, I'd like to propose the following change:

 <!-- **** DSML Value **** -->

 <xsd:simpleType name="DSMLValueType">
  <xsd:union memberTypes="xsd:string xsd:base64Binary xsd:anyURI"/>
 </xsd:simpleType>

 <xsd:complexType name="DsmlValue">
  <xsd:attribute name="valuetype" type="DSMLValueType"/>
 </xsd:complexType>

ciao,
Christine

Shon Vella wrote:

> The way that DsmlValue is currently defined would have an operation look something like:
>
> <addRequest
>     xmlns="urn:oasis-open:dsml:2"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     dn="cn=a, o=b">
>         <attr desc="objectclass">
>                 <value>
>                         <utf8>inetorgperson</utf8>
>                 </value>
>         </attr>
>         <attr desc="cn">
>                 <value>
>                         <utf8>a</utf8>
>                 </value>
>         </attr>
>         <attr desc="GUID">
>                 <value>
>                         <binary>bz5mv6g5BUWtMD0QomH1kQ==</binary>
>                 </value>
>         </attr>
> </addRequest>
>
> I can live with this, though for reasons that are purely aesthetic, I prefer the DSML 1.0 encoding of <value> which would look something like:
>
> <addRequest
>     xmlns="urn:oasis-open:dsml:2"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     dn="cn=a, o=b">
>         <attr desc="objectclass">
>                 <value>inetorgperson</value>
>         </attr>
>         <attr desc="cn">
>                 <value>a</value>
>         </attr>
>         <attr desc="GUID">
>                 <value encoding="base64">bz5mv6g5BUWtMD0QomH1kQ==</value>
>         </attr>
> </addRequest>
>
> or even maybe even:
>
> <addRequest
>     xmlns="urn:oasis-open:dsml:2"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:xs="http://www.w3.org/2001/XMLSchema"
>     dn="cn=a, o=b">
>         <attr desc="objectclass">
>                 <value>inetorgperson</value>
>         </attr>
>         <attr desc="cn">
>                 <value>a</value>
>         </attr>
>         <attr desc="GUID">
>                 <value xsi:type="xs:base64Binary">bz5mv6g5BUWtMD0QomH1kQ==</value>
>         </attr>
> </addRequest>
>
> which would make it more amenable to schema validation than the 1.0 scheme, though less so than the current proposal.
>
> Any one else have any thoughts on this?
>
> Shon Vella
> Software Engineer, Consultant
> svella@novell.com 
> Novell, Inc., the leading provider of Net services software
> www.novell.com 
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC