[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on EDXL-DE 2.0 Nov 2011 Candidate
Comments on
EDXL-DE 2.0 Candidate of Nov., 2011
Glenn
Pearson, US National Library of Medicine
Disclaimer: Comments here
are mine, and do not represent the position of NLM or any
part therein.
To the TC:
Nice improvements, particularly with respect to target areas and distribution references.
A skim of this document raised these concerns:
· What’s the recommended way for a receiving system to distinguish between DE 1.0 and 2.0 messages, assuming a common input channel?
· The “ct:” namespace is referenced long before it is defined (other than a page 7 ref to “EDXL-CT”). Consider moving some version of the content in section 3.2.10 to the beginning of the Data Dictionary.
· I suspect the XLink feature will solve the problem about how to tie related content objects & descriptions together, but what we have here as description is both repetitive (almost-the-same paragraph many times in Data Dictionary Comments) and opaque. How about just having a separate section, that gives actual examples of how, say, 3 EDXL-embedded items can be grouped with this mechanism?
· How to use the default list mechanism was not indicated in the DOM diagram, nor described generally, nor easily discerned from the Data Dictionary elements. I was wondering if the default list element is (a) an interposed level around the standard list element, (b) a replacement for the standard list element, or merely (c) an example of a standard list element. It was only by looking at the example schema that I could see that the general pattern is that of (a):
<someElement>
<ct:ValueListURL>myUNI</ctValueListURL>
<ct:Value>aValue</ct:Value>
</someElement>
Or
<someElement>
<someElementDefault>
<ct:valueListURL>someElement’sDefaultUNI</ctValueListURL>
<ct:Value>aValueFromDefaults</ct:Value>
</someElementDefault>
</someElement>
· The descriptions of the defaulting mechanism is not handled in a uniform manner. So for example, DistributionStatus is a single entry in the Data Dictionary, whereas DistributionKind also has DistributionKindDefault and DistributionKindValueList defined. I could be wrong, but I don’t think you’re trying to make a distinction here.
· It would be helpful to state that it is RECOMMENDED that any system that can store-and-forward message preserve the element order, and those systems whose primary role is to store-and-forward messages MUST preserve the element order. This would support the use of ordering for TargetArea priority.
· In addition to preserving ordering, I would like that XML comments be explicitly allowed (and their ordering with respect to elements preserved), viz:
Systems whose primary role is to store-and-forward messages MUST preserve XML comments.
It is RECOMMENDED that all systems that can store-and-forward messages preserve XML comments.
Systems that generate and/or consume messages MAY provide means for the user to respectively add and view comments.
· No default lists for confidentiality, senderRole, recipientRole?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]