[dsml-comment] Next Question

[suendermann@zenturion.de]

Another problem with DSMLv2:

DsmlValue

The simpleType DsmlValue is defined to be:

	<!-- **** DSML Value **** -->
	<xsd:simpleType name="DsmlValue">
		<xsd:union memberTypes="xsd:string
xsd:base64Binary xsd:anyURI"/>
	</xsd:simpleType>

and results are structures like

		<attr name="description">
			<value>This is the description.</value>
		</attr>

where the value may contain a String, a Uniform Resource Identifier,
or base64
encoded octets.

My intention is to use DSMLv2 batchRequests as input data for a
Java Program accessing
an LDAP Server through JNDI. Now I wonder how I can distinguish if
a value is to be
interpreted as a String, URI or base64 encoding.

Assume the following case:

I want to store a URI value as String
Example:

	<modifyRequest dn="...">
		<modification name="photo" operation="add">
			<value>file:///myPhoto.jpg</value>
		</modification>
	</modifyRequest>

How is this to be interpreted?

- Let us assume that my LDAP Server has an attribute type 'photo'
with Directory String Syntax,
and I want to store a file reference to the actual photo in the
attribute.
In that case, the sniplet above has to be interpreted as a String
which
is literally written to the LDAP Server.

- now assume my attribute 'photo' is of Binary Syntax.
In that case, the file URI has to be resolved and the contents of the
file
becomes the attribute value.

Does an DSML Server have any chance to distinguish these cases
without any
knowledge of the underlying LDAP Schema? I do not think so - the
resulting content
of an XML file is identical down to the bytes of the
'file:///myPhoto.jpg' value.
The URI string is a subset of a character string.

Therefore, I would say that the above definition of a DsmlValue is
not sufficient.

A possible solution could look like:

	<xs:complexType name="DsmlValue">
		<xs:choice>
			<xs:element name="utf8" type="xs:string"/>
			<xs:element name="URI"
type="xs:anyURI"/>
			<xs:element name="base64"
type="xs:base64Binary"/>
		</xs:choice>
	</xs:complexType>

and defining that the URI choice means that the content of the
specified location
is the attribute value. The next question is already lurking behind
this: Is the
loction content to be interpreted as byte or character stream ? ...

The above code sniplet then becomes

	<modifyRequest dn="...">
		<modification name="photo" operation="add">

<value><utf8>file:///myPhoto.jpg</utf8></value>
		</modification>
	</modifyRequest>

or

	<modifyRequest dn="...">
		<modification name="photo" operation="add">

<value><URI>file:///myPhoto.jpg</URI></value>
		</modification>
	</modifyRequest>

leaving no space for misinterpretation.

Unfortunately, this is not compatible with the existing schema: An
additional tagging
level is introduced. But the confusion is resolved.

I have thought about a better solution that would allow the ordinary
DsmlValue type still
be tagged as above but did not find one that convinced me.
Under the premise that
DsmlValue type shall be replaced wherever it is used by an
equivalent definition that
does not invalidate existing valid DSMLv2 XML documents, you end
up with redefining at least

- AttributeValueAssertion
- DsmlAttribute
- DsmlModification
- MatchingRuleAssertion
- a separate type for each of SubstringFilter.initial, any, final

all of which have a common core (Base Class for object-oriented
point of view):
the DsmlValue.
So I'd leave this for discussion - perhaps for DSML V3.0.

--
Dr. Annette Sündermann
Zenturion GmbH
Postfach 1248,  85730 Ismaning
Tel.: 089/638 76 706 Fax: 089/638 76 707
Internet: http://www.zenturion.de