That's great, David... thanks! A few quick notes on first inspection:
* In the enumeration of <messageType> I assume the intended spelling
is "Response". (Presumably just typo.)
* Likewise, I think the spellings of the element names should be
"contentObject", "confidentiality" and "llConfidentiality". (For
discussion: might we want to change that last one to
"lowestConfidentiality" just for readability?)
* For the default namespace I'd suggest we substitute one in the
OASIS style, like
"urn:oasis:names:tc:emergency:edxl:distribution_1.0". (Among other
things, using this URN form might help alleviate any confusion
between the namespace value and the schema location.)
* Regarding the structure of <contentObject>: I think our intent,
eventually, was to rename the CAP <resource> element to
<contentObject> and reuse this extended structure. So might it work
better if the choice were between the explicit, separately-namespaced
XML (as in this draft, but with the name lower-cased) and the current
content of <resource> but without the additional wrapper elements?
(The future effect on CAP would be to allow the in-lining of other
XML content without having to uuencode it, which strikes me as a good
thing.)
* I'm not quite clear on your comment "We need to develop pattern for
URN"... it appears to be in the context of the <valueListUrn>
element. Is an additional restriction needed beyond requiring that
it be a valid URN?
* Regarding your comments on <targetArea>... I don't think we
intended to support separate targetings for individual
<messageElement>s. The idea, I think, was that the whole message has
a common targeting, which might be the union of multiple
<targetArea>s. So there really wouldn't be any need for a reference
ID on <targetArea>s.
Again, thanks for all your great input at the meeting and for taking
the first cut at the schema. (And I'm throwing the full weight of my
influence with DTRA behind getting you your funding. ;-) )
- Art
