[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: GJXDM Reuse and Specific Technical Issues
Hi Everyone,
Before I dig into specifics, let me state three things in relation to the previous email thread on the “emergencyType” differences.
So, now focusing on specifics:
First, some thoughts on “emergencyType”: There are two separate issues here under consideration: the naming design rule and the difference in modeling approach. The naming design rule is debatable and probably arbitrary as long as your naming is consistent. The modeling approach and semantic differences between the concepts is, in my opinion, the more important issue.
To me, the first thing to get consensus on is how we model an event. In the Distribution schema you use an event type enumeration; however, in the CAP schema you are using a string. One problem in this setup is that you could not validate before hand whether the event type in the distribution header was the same as (or compatible with) the description of the event in the CAP message. In comparison to GJXDM, an event type code to distinguish events could be modeled as a constraint on the event name or as another attribute in the GJXDM Event Type (akin to a Class). Or, if the event types are significantly different you may want to extend Event Type to add attributes. For extensibility and flexibility, I would prefer an Event as a Class with an optional category property to classify (or categorize) the event within a taxonomy. In recognition of the fact that there may be other existing taxonomies that people want to categorize their events under, the “EventCategory” element should have a qualifier attribute, possibly called “source”, to identify an external classification scheme (as is done in ebXML and UDDI registries).
Some thoughts on GJXDM:
Other miscellaneous thoughts: 1. On the Distribution schema – what is the functional requirement for this? I say that especially in light of the fact that it is an optional element in the Standard Message Format document. If the business case was strong enough, I would not think this would be optional. In general, I like the concept but am concerned that such a potentially complex issue should be designed after a clear articulation of the functional requirements we are trying to solve. Especially, when some could argue that distribution should not be determined by the originator but dynamically based on a publish/subscribe approach (with proper authentication). Also, there seems to be some overlap between the elements in CAP and the elements in the distribution schema.
Well, that’s enough for now. I look forward to working with you on these issues.
Regards,
Michael C. Daconta Metadata Program Manager Department of Homeland Security tel: (202)692-4340 email: michael.daconta@dhs.gov
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]