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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency-if] Excerpts from Issues for EDXL-DE we need to add to issues list for 2.0


Dave -

Thanks for this compilation. Very useful.

On one point:

Art agreed to be the coordination
point for the ITU-T, Tom and Dave will continue with the sensor work in the
IF-SC and represent the TC at the NIST and other sensor standard discussions.

I hope that this activity remains coordinated with the OGC and ISO. There
are numerous sensor web/network activities being rapidly progressed in
both the OGC and ISO, including a JTC-1 activity. I would also encourage
the EM TC to take a look at the Sensor Fusion RFI that the OGC recently
released.

http://portal.opengeospatial.org/files/?artifact_id=38987

Regards

Carl

> Don
>
> Here are some issues I have gleaned from the past.  I was not the issues
> list keeper and there have been many things deferred but may now be lost.
> I
> believe Rex is going to send you a current example of how to maintain an
> issues list.
>
> Dave
>
> 1.	EDXL-DE Update
>
> Tim has agreed with the resolution that EDXL-DE can have multiple
> contentObjects with one and only one payload each, and one and only one
> DistributionType, so that no contentObjects could be of a type different
> than the DistributionType. Patti has incorporated this into the latest
> version of the draft. This was the only remaining issue on the EDXL-DE
> draft.
> ____________________________________________________________________________
> _________________________________________________________________
> a.	Dave said there was a deadline of 8 January to respond to ITU.
> Elysa stated that we certainly want to respond to each of the 3 issues
> that
> have been discussed; we have no requirement to respond to ITU by that
> date.
> As Jamie instructed us, the OASIS staff has the responsibility to address
> the ITU.  We will put these topics on the agenda for discussion but
> discussion could also begin now on the list.  Dave is most concerned about
> points that effect the DE and will get with Rex on the issues.  Elysa
> added
> that all three points will require special discussion and may need
> separate
> meetings to address them
>
> ____________________________________________________________________________
> ___________________________________________________________________________
> Dave Ellis has identified some possible issues with various applications
> using FIPS 5, FIPS 6 and UNLoCode. Dave is continuing to research the
> issue
> and will have a more formal listing for the issues raised.
> ____________________________________________________________________________
> __________________________________________________________________________
> 2.	EDXL-DE
> a.	Remaining Issues
> 			The remaining issue with the DE is with regard to
> the <any> element.  There was much discussion on the call about this
> relative to Dr. Iannellas comments on the list.  A variety of opinions
> were
> discussed.  Signatures for target area and differed for a future
> resolution.
> It was agreed that we would add a clarifying comment to the data
> dictionary
> as follows.  We realize this is possibly not optimal but can be revisited
> at
> the next revision.
> b.	Changes since 60 day public review are being summarized by Patti.
> c.	Path Forward
> 			Dave Ellis pointed out again how important it was to
> get the DE through as soon as possible.  They are using it in the Alerting
> Framework and must move ahead.  We discussed the fact that the changes
> made
> to the DE since the 60 day comment period were minor in nature.  Since
> there
> are changes, the document must go back out for a 15 day public review.
> The
> reviewers will only be able to comment on the items that have changed.
> Patti will make the changes per our call today and post it to the site.
> All
> agreed to review the document and schema to make sure all comments are
> appropriately addressed.  We will have a meeting January 17 at 12:00 EST.
> A
> vote will be taken to submit this draft for a 15 day review.  This vote
> will
> require a full majority vote.  An electronic ballot is not necessary.
> Once
> we have done this, Mary will post the documents on the OASIS site (either
> 1/17 or 1/18).  The 15 day review will run through Feb 2 or 3.  We will be
> able to address any comments raised during that period until Feb 6.  We
> will
> call a special meeting if necessary to address any comments.  We will have
> a
> regularly scheduled meeting on 2/7.  At that time we will vote to 1)  to
> approve this document as a Committee Specification and 2) to take this
> Specification to OASIS for a vote to ratify as a Standard.  It will be
> submitted to the OASIS wide community on the 15th.  The actual OASIS wide
> ballot will run from March 16-31.
>
> 3.	Consideration of Dr. Iannella's proposal for the EDXL DE model
>
> 		The group noted Dr. Iannella's formal objection to
> consideration of the current EDXL DE draft as a proposed committee draft.
> Elysa recognized the amount of thought and effort Dr. Iannella put into
> his
> proposed model, and apologized to him in absentia for not acknowledging it
> earlier.
>
> 		She then asked the group if they had fully considered the
> model proposed by Renato.  Several members (specifically Rex, Tom, Gary,
> David, Michelle and Sylvia) expressed that they reviewed the comments and
> felt like each had been addressed.  Rex said that Renato's model had not
> been ignored, but that he himself had referenced it during the initial
> discussions and had adopted many of its ideas during the interim phase,
> and
> that it had proven very helpful. However, the DOM model seemed to be the
> consensus of the group. Gary said that he liked the information model very
> well from a design standpoint, but that as work progressed they had
> decided
> that creating a more meaningful organizational model would require a
> different structure. The current proposal combines ideas from Renato's
> model
> with other members' ideas, as well as the concepts formulated at the New
> Orleans meeting. Art expressed concern that a model that was originally
> provided as a suggestion to the committee is now being framed as an
> alternative. It was also noted that Dr. Iannella's model was never adopted
> by the committee.
>
> 		The committee then considered whether it would be useful to
> have an information model in addition to the DOM. Carl brought this up and
> informed us that both a logic and data model are represented in the OGC
> specifications.  Rex felt that it might be confusing to add the
> information
> model, and would cause a delay in release of the proposal. Patti suggested
> including the information model in the "cookbook" implementation guide
> she's
> working on.  The group agreed that the current DOM would be the only model
> in the specification.
>
> 4.	Outstanding EDXL DE issues
>
> 		We discussed how we are going to manage the issues and
> versions in this fast-paced week of trying to finish up this Committee
> Draft.  Michelle started an issues list via the list.  These with their
> status are contained in subsequent paragraphs.  We are asking anyone at
> this
> point when an issue is raised to please also offer a proposed solution for
> discussion and any ramifications they envision.  The document in its
> current
> form will be numbered EDXL/DE 0.1.  Each time we make changes, this number
> will increment until we get to the 1.0 committee draft.
>
> 		Michelle led the discussion on outstanding EDXL DE issues.
> She asked for volunteers to maintain a more formal list of issues, and Art
> volunteered to do so taking the initial feed from Michelle's' handoff
> today.
> He strongly encouraged anyone submitting an issue to include with it an
> affirmative suggestion.
>
> 		David agreed to write up the issue of value list and value
> pairs being able to appear multiple times, and to provide his suggested
> implementation.
>
> 		Michelle is going to write up, for further discussion, the
> choice among URI, derefURI, and XML namespace.
>
> 		There was discussion of the appropriate name for the
> location element. Everyone liked the idea of including UN in a way that
> wouldn't be confusing. Art suggested using locCodeUN, and the group
> agreed.
>
> 		Sukumar noted that the current draft could use more of a
> history, which David and Tom are working on. Elysa offered to help with
> that
> effort. To offer an example usage scenario, Sukumar will provide the
> prototype he used for his earlier demonstration to Michelle by Thursday.
>
> 		Julia will get the identifier number and other designators
> required by OASIS from Mary.
>
> 		The following details were submitted by Michelle to the list
> but are put here as well.  All of the "PROCESS", "ISSUE" and "EDIT TASK"
> items were noted in the meeting except the third PROCESS note.  That is
> Michelle's suggestion as to how to facilitate communication. It might also
> be good if we also prefaced the subjects of our emails as "EDXL_DE_ISSUE,
> for example.
>
> 5.	EM data exchange initiatives
>
> 		The group discussed changes in U.S. agencies and warning
> initiatives that may impact the committee's work. Dave updated the group
> on
> NorthCom, which has been given the lead in meetings to take place in early
> January, and which he will be assisting. DMIS is now capable of handling
> EDXL content, but is not able to store data having to do with pre-event
> detection or tracking of individuals. The Domestic Nuclear Detection
> Office
> (DNDO) is doing a joint pilot with the Department of Justice. Tom and Dave
> are going to be leading the sensor architecture effort. Infrastructure was
> going to look at existing sensor systems,  and whether they would
> recommend
> to the committee that they work on a new sensor schema. DNDO has expressed
> interest in using the ANSI 4242 standard as content for an EDXL message.
> Tom
> is waiting to hear back from Michelle on her sensor standards survey.
>
> 		Liaison Assignments:  Art agreed to be the coordination
> point for the ITU-T, Tom and Dave will continue with the sensor work in
> the
> IF-SC and represent the TC at the NIST and other sensor standard
> discussions.  Patti agreed to represent the TC to the HS Standards group
> she
> has just joined.  Elysa is to have a telecon with Jamie and Mary of OASIS
> about liaison relationships.  DNDO specifically asked Elysa to look into
> how
> they would become members of OASIS and in what capacity they should/could
> serve.  They also asked about how MOA and other type of relationships
> existed between OASIS and other standards bodies, specifically ANSI and
> OGC.
>
>
> 		A persistent issue has been the ability to test prototype
> standards. Dave currently doesn't have anyone test the DE with, but should
> be able to do so with the MyState site soon. Next would be CIST, in order
> to
> test security, including SSL. After that, the committee should consider
> interface standards to commercial systems.
>
>
> 6.	EDXL-DE Progress
>
> 		The current plan is to put the draft revision out for
> comment on January 7th. The key change is that the ANY element has been
> put
> back in. With the addition of the choice statement, signatures will no
> longer automatically work. The ANY element will be required at the end of
> a
> sequence in order to sign a content object.
>
> 		There was discussion of whether it was possible to put a
> namespace in an element without first declaring it. If not, that will
> require another change in order to have an ANY element and an ANY
> attribute.
> This should be checked by others with validation tools. If it doesn't
> work,
> that will require a second change to the draft.
>
> 		Art Botterell has proposed a change in methodology for the
> future, which is to create the data dictionary first, validate it, and
> explain what each element is intended to accomplish. After this is
> complete,
> the schema could be created. Dave proposed instead doing both at the same
> time. Since Art's proposal had to do with methodology rather than results,
> Renato's issue is the only one remaining. Patti is going to finalize the
> draft and get it out on the list so that Renato can comment if he wishes.
> She will change both the document and the XSD so they will match.
>
> 		Once the new draft is OK'd, the 15-day review period can
> begin. That would allow the ballot to go out for review to the general
> membership by the end of the month, and for general voting to begin on
> February 1.
>
> 		Gary has published a prototype of the DE, but not many
> people have used it. He may try to get data from Dave to post internally.
> He
> asked whether the committee should start working on a "cookbook." Art
> suggested publishing sample code for the transport layer. There was
> discussion about implementation issues and whether WSDL should be the
> focus,
> as well as whether Java provides the most transportable architecture.
> Elysa
> said it has reached to the point where someone needs to put sample code
> out
> on a cookbook. Dave questioned whether that would be possible given that
> many of the examples will require sensitivity to security issues. Elysa
> emphasized that no secure data should be in the cookbook. Art noted that
> even "pretend" sensitive data can be complicated, since there isn't a
> security version of "lorem ipsum" yet.
>
> 		The remaining to-do item is to check with Mary McRae to make
> sure assumptions about the schedule are accurate.
> ____________________________________________________________________________
> ____________________________________________________________________---
> Distribution Type issues
> .	Mandatory "enumerations" which are not complete and are causing
> adoption and semantic ambiguity issues especially in compound messages or
> workflows.
> .	Must determine use within EDXL distribution system
> -	Why have this tag anyway? (framework versus edge system)
> .	Composition of "distributionType" (URI and/or XRI)
> -	Registered EDXL Distribution Systems
> -	Distribution System COI label
> -	Content Objects Schema / Context
> -	Schema/Context Distribution Type
> .	Provide guidance for "distributionType" creation and mapping between
> EDXL Distribution Systems (must be unique)
> ____________________________________________________________________________
> ____________-
> Security Labeling Issues:
> Controlled Unclassified Information and specific metadata from Federal
> agencies needs to be discussed for ContentObjectZero
> ____________________________________________________________________________
> ________________
> PROCESS: The documents would be clearer to differentiate as separate
> entries into KAVI.
>
> Suggestion: Name the documents by version numbers, "0.1", "0.2" ...
>
> Proposal: Put the file of the draft specification in KAVI as
> "EDXL_DE_Draft_V0.1.html" and add files as they are incremented rather
> than adding a revision to the existing KAVI entry.
>
> Action: Michelle will check in the first of these drafts and update
> them after each meeting this week with a new entry and version number.
>
>
> PROCESS: We need an official keeper of the issues.
>
> Suggestion: Rope in a volunteer to maintain a table of issues.
>
> Stuckee: Art (with backup support from those who volunteered on the call)
>
>
> PROCESS: We need to keep the types of material flowing through email
> and other forms of converse clear.
>
> Suggestion: Going forward, for ease of differentiation, in
> communications please note what is a content issue as "ISSUE:" , what
> is a document spiffing up or formatting goof as an "EDIT TASK:" and
> what is a point-of-proceess as "PROCESS".
>
>
> ISSUE: Use of multiple <value> elements in conjunction with a
> <valueListUrn> element, where the values are from the value list,
> should be supported.
>
> Originator: Dave Ellis
>
> Rational: This reduces the reuse of the container elements (<keyword>,
> <senderRole, <contentKeyword>, etc...) and the need to repeat the list
> name in each of these container copies.
>
> Example:
> <consumerRole>
>         <valueListUrn>railway:sensor:hazamat:alertRecipien<valueListUrn>
>                 <value>hazmat.northLine@goRail.com</value>
>                 <value>application/CAMEO/plumeReport.bat</value>
>                 <value>fireDepartment@centerCity.gov</value>
> </consumerRole>
>
> Suggestion: Allow multiple <value> elements with an associated
> <valueListUrn>.
>
> Proposal: Within the "container" elements (<keyword>, <senderRole,
> <contentKeyword>, etc...) require one-and-only-one <valueListUrn>
> element and one-or-more <value> elements.  Also, make certain it is
> documented that each of the container elements could be used
> more-than-once.
>
> Action: Proposal accepted.  Changes to be made in the schema and
> specification by Michelle.
>
>
> ISSUE: Add a <location> element to the <contentElement>.
>
> Originator: Dave Ellis
>
> Action: Dave to write up rational and proposal.
>
>
>
> ISSUE: A <choice> between <uri>, <derefUri> and
> <namespacedXMLContent> should not be forced in a <contentObject>
> element.
>
> Originator: Michelle Raymond
>
> Reasons: 1. The <uri> element may be desired in the same
> <contentObject> as one containing a <derefUri> element to direct to
> where the dereferenced document is held.
>         2. The <uri> element may also be desired in the same
> <contentObject> as one containing a <namespacedXMLContent> element to
> direct to where the XML document is held.
>
> Suggestion: Take out the <choice> element and set each of the three
> elements to attributes of minOccur="0" and maxOccur="1
> .
> Side-effect: This does allow for a <contentObject> to not have any of
> the three element types as sub-elements.  These seems ok, as sometimes
> the synopsis is all that needs to be communicated.
>
> Proposal: Several were mentioned  (see action.)
>
> Action: Michelle to write up the potential proposals discussed.
>
>
> ISSUE: The name for the UN/LOCCODE, <location> in the <targetArea>
> element is too generic.
>
> Originator: Michelle Raymond
>
> Reason: "location" has too broad of a potential meaning.
>
> Suggestion: Rename <location> to <locCode>.
>
> Proposal: Rename <location> to <locCodeUN>.
>
> Action: Proposal accepted.  Changes to be made in the schema and
> specification by Michelle.
>
>
> ISSUE: <originatorRole> and <consumerRole> provide less confusion
> against <senderRole> and <recipientRole> but do not disambiguate
> clearly.
>
> Originator: Michelle Raymond
>
> Reason: ambiguity as to context is not available from the naming.
>
> Suggestions: Option 1: use <senderRole> and <recipientRole> in
> <EDXLDistribution> and use <messageOriginatorRole> and
> <messageConsumerRole> in <messageObject>.
>
>              Option 2: use <distributionSenderRole> and
> <distributionRecipientRole> in <EDXLDistribtion> and use
> <contentOriginatorRole> and <contentConsumerRole> in <contentObject>.
>
> Proposal: Leave as is.
>
> Action: Leave as is.
>
>
>
> EDIT TASK 00: Review draft of Specification
> Stuckee: EVERYONE - provide issues with reasons and suggestions
> Stuckee: EVERYONE - note consistency issues in text, typos, formatting
> problems, quibbles and nits about document structure, etc.
>
> EDIT TASK 01: Get the [Document Identifier as per OASIS Artifact
> Naming Guidelines]
> Stuckee: Julia (Thu.)
>
> EDIT TASK 02: Get the [OASIS Document Number]
> Stuckee: Julia (Thu.)
>
> EDIT TASK 03: Add links to Chair and Editor company names
> Stuckee: Michelle (Thu.)
>
> EDIT TASK 04: Add [Comma-separated keyword listing]
> Stuckee: Sukamar (Thu.)
>
> EDIT TASK 05: Determine the OASIS Conceptual Topic Model Area - [Please
> refer to (link) for appropriate topic area]]
> Stuckee: Julia (Thu.)
>
> EDIT TASK 06: Put in reference to CAP 1.1 for related spec.
> Discussion: This should be 'related' as in an example of how the
> <namespacedXMLContent> may be used.
>
> EDIT TASK 07: Add more History.
> Stuckee: Tom (Thu.)
>
> EDIT TASK 08: Add or delete Example Usage Scenario
> Stuckee: Sukamar (Thu.)
>
> EDIT TASK 09: Check for consistent bolding and bracketing
>
>
> 7.	EDXL timetable
>
> 		To fulfill its goal of having a committee draft ready for
> vote by the end of the week, the group agreed to meet on both Wednesday
> 3:30
> EDT and Thursday 9:00 EDT to continue the discussion.
>
>
>
> Respectfully submitted,
>
> Julia Ridgely, Secretary
> OASIS EM-TC
> President
> Long Branch Systems
> (443) 604-8699
> 1.	Outstanding EDXL DE issues
>
> 		Discussion resumed of the remaining EDXL-DE open issues as
> posted by Art on the site in the 8/18/05 issues list.
>
> 		Michelle thanked everyone who sent comments and
> contributions to the draft, and said there were three remaining issues to
> be
> considered.
>
> 		The first was issue 9, the proposal not to encode payloads
> that can be delivered by other means. This issue concerns the size of the
> DE
> in some implementations where there is limited processing capability and
> bandwidth at the point where the DE must be processed.  The size issue
> mainly concerns the <nonXMLContent> and the <derefUri>.  Discussion on the
> topic continued for some time.  Unfortunately, Kon who raised the issue
> could not be on the call.  We discussed the size of the DE and the fact
> that
> the way it is currently specified, the DE could be very large and could
> actually have an undetermined size since it could contain live video in
> the
> <nonXMLContent>, as a worst case example.  Where most senders will be able
> to calculate the size and store it in the DE, in some cases, the sender
> will
> not be able to determine this size.  David very much needs the ability to
> have a DE that can have a large <derefURI>.  We discussed how to
> accommodate
> both high- and low-bandwidth users. Rex offered a motion to document this
> as
> an open issue in the draft but withdrew it after further discussion.  Art
> moved and David seconded a motion to note this as an implementation issue
> that is out of scope for the specification.  All agreed.
>
> 		As an aside, David said he had not been able to get
> clearance for the example he offered, so it will be omitted not only from
> the draft but from the implementation guide and wiki for now.
>
> 		In consideration of the issue of low-bandwidth users, Gary
> made a motion that was seconded by Rex to make the <size> be mandatory
> whenever <derefURI> is used. This will allow systems the ability to know
> the
> size prior to ingesting the entire message.  It was discussed that this
> will
> only help where the parser does not require the entire message to be
> ingested at once.  There was also discussion about whether it would make
> sense to have <size> be mandatory for URI as well but decided against.  We
> also discussed whether <size> should be able to be indeterminate, e.g.,
> streaming video.  We decided not to do so at this point since streaming
> data
> is a different situation and should be considered separately when raised.
> The motion passed unanimously.
>
> 		The second issue, issue 10 on the list was raised by Renato
> to rename <derefURI> to <contentData>. We agreed this is a more fitting
> name, however the EDXL-DE will be inconsistent with CAP 1.1 on this point.
> We agreed that when we align these standards at CAP 2.0, we can make the
> change in CAP from <derefURI> to <contentData> at that time.  A motion was
> made by Michelle and seconded by Art to make this change in the DE.  The
> motion passed unanimously.  Michelle will take care to make sure all
> appropriate references in the document are changed.
>
> 		Issue 11, a proposal by Renato to change <valueListURN> to
> <valueScheme>, was discussed. The impression of the group was that this
> issue was cleaned up with the resolution of Issue 8 to disambiguate
> <explicitAddress>.  We discussed the proposal and looked at re-opening
> issue
> 8.  We agreed that was not necessary.  A motion was made by Art and
> seconded
> by Michelle to respectfully decline the suggestion to rename
> <valueListURN>.
> All were in favor.
>
> 		All issues had been addressed and we began to do a final
> review of the remainder of the specification.  Each section of the draft
> was
> reviewed by the group with Michelle leading the discussion.  Several
> editorial corrections were made.
>
> 		Art reviewed comments he has received from the public on the
> Distribution Element. They include making digital signatures mandatory, a
> tag for language used, and a question about whether there should be
> multiple
> XML or non-XML elements. The National Wildfire Coordinating Group
> requested
> an incident identifier and description. Art will be preparing and
> circulating a list of all comments and issues.
> ____________________________________________________________________________
> ______________________________________________________________________
> Open Issues
>
> 1.	General Requirement "Incident and Event Reference".
>
>  In the EDXL Distribution Element, this is handled using a "keyword"
> element
> providing the capability to link to any value from a discrete managed
> list.
> This could be used to specify an incident or an event using the Uniform
> Resource Name (URN) of a published list of values and definitions.  This
> approach was pursued in an attempt to make the standard more flexible.
>
> ISSUE:  This approach makes the assumption that each resource message -
> even
> a resource message containing multiple payloads - will be referencing the
> same incident or event.  This assumption must be tested and validated.
>
> This issue will be addressed during the OASIS technical committee review
> process, with input and feedback provided by the Standard Working Group
> through EDXL project team OASIS members.
>
> ____________________________________________________________________________
> ________________________________________________________________________
>
> These are issues from the Face to Face:
>
>
> Review issues identified during Sept F2F to be addressed in DE follow-on.
> Dave Ellis to provide brief context for the current unmet needs in the DE:
>
> 1. Acknowledgement (reply to/error to) (Optional, could be 1.1)
> Does the message reach the end user?
> Define where the grid starts/ends - given distribution technology
> Requirement:  The DE shall provide the sender with feedback to confirm
> transmission of message to the redistribution system(s).
> Note:  The DE should support load balancing in methods of redistribution,
> but it is understood that this is not a requirement of the DE
> What is in the 1.1 draft should be reviewed (string or valuelistURN or
> value
> scheme)
> Responsible - Included in draft now as string, need to change to structure
> of explicit address.  Hans
>
> 2. Hop count - sounds like a system requirement, not a DE requirement
> (router specific - Hans/Jeff/Don)
>
> 3. Distribution type - mixed mode, content objects with different
> distribution types.  Note - dependency on current approved standards
> RM/HAVE.
> Needs to be "fixed" in next revision.  Fix or do differently.
> Maybe recommend one distribution type per message, need to determine
> whether
> the structure needs to be single distribution type or single content with
> multiple distribution types. (2.0)  Suggest valuelistURN so that other
> standards (RM/HAVE doesn't have to change).  Possibly need to add t.
> Topic
> for discussion during IF-SC meeting.  Discussion about adding tags for the
> routing params (update/cancel..)  Those having specific interest/knowledge
> (Gary/Tim/Rex/Michelle - need diversity and history)
> FORWARD SHALL BE A TYPE - with example and explanation (base64 encode full
> message, security ramifications, tracking/logging)
>
> 4. Re-evaluate header vs content (2.0)
> What must be fixed is putting info about the content in the header.  What
> is
> used for policy decisions and where it goes - distribution vs
> contentObject.
> If it has to do with routing whole message - Distribution.  If it has to
> do
> with routing a piece of content based on specific purposes, it would be in
> the contentObject.  This will be worked in IF-SC meetings - those having
> particular interest/knowledge - Michelle/Rex/Gary/ -
>
> 5. Conformance section - Dave - five levels of routing,
> policy/distribution
> should include conformance for the routing points.
> There is a need for different levels of conformance.
> DE conformance section must be added, it will have to grown.
> Gary - be careful of over specifying it.
> NIMS-STEP folks have offered to provide input
>
> 6. Policy methods for routing  - emergency message routing
> What are the unique needs of the routing element for emergency needs.
> Where does routing detail go?   Determined that there must be a Routing
> Specification  (Jeff/Hans/Don/Michelle - others as needed)
> 1.	Capture detail experience about routing (Jeff/Hans/Don working with
> Dave)
> 2.	Create bullet points of what a basic routing capability should be
> for within the DE spec.  A full blown spec will likely follow.. (Rob)
> 3.	Routing spec for EM will follow and have its own conformance spec.
> (levels vs capabilities - 5 discussed in the early days, Gary added that
> this should be capabilities)
>
> 7. Name space for DE - Name space restriction on content object
> NO DE wrapped in a DE - don't layer Des, specifically for security reasons
> Consensus - we will not do this.  (see forward reference in distribution
> type)
>
> 8. URI instead of URN
> URN - allows global unique id, doesn't require going to the web for
> reference (URNs are controlled - Rex)
> URNs are not affective for small county jurisdictions (Don)
> High speed routing - URN and locally specified lists can use URI (Gary).
> DM-OPEN is taking code lists from NIEM code lists - that can be locally
> available
> URL in current spec mistake,
> Don- should be able to use URLs
> Question - should the valuelist URN/URI/URL/Code list all be allowed.
> Dave will try to provide detail need for URN exclusive - for high level
> systems
> Specific changes to spec - changes from spring to any URI and change the
> name to valuelistURI (Jeff/Don/Rex/Hans -
>
> 9. Non-XML Content - add new element for digest type and update digest to
> remove SHA-1 (refCOID and COID) - both XML and non-XML content.  Structure
> (not a string).  Examples need to be included in spec for clarification.
> Doug - examples/Hans - update 1.1 tech (CSV), use case (multiple content
> object)
>
> 10.	Area - readdress with next revision, See EM Routing concepts Version
> 4, Michelle - support multi area geometries, include GML Where, Hans -
> order
> of preference for areas.  Michelle - add tagging of level of detail, Doug
> -
> need FIPS (SGC).  Request GIS-SC to weigh in and provide guidance
> Particular
> interest Carl/Rex/Michelle/Doug/Hans/Rob
>
> 11.	Confidentiality and Combined confidentiality - Enumerated list? URN?
> This topic must be covered in the next revision.    Keep required but make
> it a choice - between a string and valuelistURN.  Can't be ignored.  Rob
>
> 12.	xmlContent - OOPS - need to change the name because it is not a
> valid XML tag name.  Needs to be fixed.  "ContentXML"  - Hans
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]