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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

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