- non-determinism model present. For example the use of attribute
senderType, recipientType, and keyType attributes can hide the actual
content model of the parent elements. Creating separate type definitions
for each sender, recipient, or key (e.g., federalSender, civilianSender) and
specify precisely what kinds of values/structures are allowed for a
particular type can improve the model explicity and clarity. This would
allow the parser to precisely validate the content. This practice may not be
applicable to the DRM as a meta-data schema, since role-based element names
(e.g., federalSender, civilianSender) can make the schema too less generic.
However, a code list (perhaps with extension mechanism) would help clear out
the ambiguity associated with the attribute. For example, senderType could
means many things according to the description. One could think of
senderType as Person vs. Company vs. Computer, or ebMSEndPoint vs.
WebServiceEndPoint vs. EdiEndPoint etc. (01)
----------------------------------------------------------------------------
----
Boonserm (Serm) Kulvatunyou, Ph.D.
Guest Researcher
Manufacturing System Integration Division.
National Institute of Standards and Technology
On Assigment from Oak Ridge National Laboratory
100 Bureau Dr. MS 8260 Gaithersburg MD 20899-8260
phone: 301-975-6775, fax: 301-975-4482
mail: serm@xxxxxxxx <mailto:serm@xxxxxxxx> , http://serm.homeip.net:8080
<http://serm.homeip.net:8080/> (02)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/drm-public/
To Post: mailto:drm-public@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/drm-public/
Shared Files: http://colab.cim3.net/file/work/drm/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?DataReferenceModel (03)
|