Re: [emergency-msg] RE: CIQ

Rex, et al,

It certainly does not mean re-working the spec. CIQ would bolt on to our spec EXACTLY as it does now. But using CIQ (according to CIQ’s own documents) means defining how CIQ is used. This may mean adding a section on CIQ implementation as applied to RM that answers the questions. It may also mean customizing the CIQ attribute value lists at some point (1.1?) I have an idea on some of the question answers, almost always answers of a “simplify/clarify” variety. The problem is not that CIQ is too complicated. The problem is that it can be implied to be too complicated. By not answering the questions we are allowing the implication to be made. One further issue may be relevant. I read the CIQ 3.0 document of 17 Nov 2007, which simplifies a lot of what was really complicated in CIQ 2.0. 3.0 is a real improvement, but I think is still a committee spec. Are we after 3.0, which is good, or 2.0 which is MUCH LESS good?

R/s

Gary A. Ham

http://grandpaham.com

703-899-6241

Grandpa can do IT!

From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Saturday, December 29, 2007 2:44 PM
To: Gary Ham; emergency-msg@lists.oasis-open.org
Cc: ejones@warningsystems.com
Subject: [emergency-msg] RE: Getiing Ready!

Thanks Gary,

My initial response is "What does this mean for finishing up EDXL-RM?"

Offhand it sounds like we would need to completely rework the spec, but I suspect that's not actually the case. I think that in practical terms, the more work required, the less likely it is that we can do it. So in terms of stirring up a hornet's nest, I'd say "Yup, it does that."

So we need to understand how much work this means, and how many person-hours we have available to us to spend on it.

At 12:56 PM -0500 12/29/07, Gary Ham wrote:

Folks,

I have just completed an initial read of the entire 3.0 CIQ Specification Document. I have tremendous respect for what they have done. A great spec!!!! CIQ provides common ground for addressing, naming, and relating names and addresses to parties, yet is flexible enough not to compromise specific system requirements. Its code lists for attributes (e.g., "city" as a name attribute for<municipality> or "last name" as a value for <NameElement> allows these values to be renamed as necessary. The elements themselves are fixed. This is very interesting to me. Flexible structure is not an oxymoron. It lives in CIQ.

Since we're just using CIQ this shouldn't involve much work.

Quite frankly, we may also want to review using the GeoRSS element in CIQ Address in place location in all of our specs. It is fairly simple, relatively clear, and is GML compatible. It might be better than our "wheel reinvention."

This involves too much work, so I don't think its feasible. Feasibility has little to do with the merit of the idea.

Finally, I now even have a reason to consider using both elements and attributes in a spec. As I read CIQ, all elements are MUST understands for all CIQ compliant systems. Attributes are MAY understand and might be SHOULD understand. But CIQ compliant systems are not expected to use, or even understand all attributes and their possible values. Some might not understand any of them. Think of attributes in CIQ as pre-defined <parameter> tags, as parameter is defined in CAP, that are applied to the element in question rather than the entire message.

I can't tell if this requires any work.

That said, I (actually the CIQ spec) have a few questions on our CIQ adoption. The following quoted material below is from the CIQ spec. Adopting CIQ correctly means answering the questions represented by the bullets below. Have we done so? If so, have we documented it? Documenting our answers to these questions would go along way toward removing the ambiguity that exists between our very nice examples that use CIQ and our relative lack of explanation of where the CIQ portions of those examples come from.

We have a fairly large bucket of suggested places where more "examples" are requested. We have to decide priorities by person-hours available to do the work.

"Following are the features of CIQ specifications that assist in customisation of the specifications to meet specific application or data exchange requirements, and the details of customisation SHOULD be documented and agreed (if involving more than one party in data exchange) at application/system design time to enable automating interoperability of information/data represented using CIQ specifications at application/system run time:

· List of all elements of CIQ XML Schemas that SHOULD be used in the exchange. This includes details of which elements are mandatory and which elements are OPTIONAL

16 messages each with its own contact info/location info.

· List of all attributes of CIQ XML Schemas that SHOULD be used in the exchange. This includes details of which attributes are mandatory and which attributes are OPTIONAL

16 messages each with its own contact info/location info.

· The approach that will be used for Code Lists (Option 1 or Option 2)

I don't understand.

· The code list values that SHOULD be used for each CIQ code lists. This includes updating the default XML Schemas for code lists (Option 1) with the values to be used and updating the default genericode based code lists (Option 2) with the values to be used. These code list files SHOULD then be implemented by all applications/systems involved in data exchange. If genericode based code list approach (Option 2) is used, then the XSLTs for value validation SHOULD be generated and implemented by all applications/systems involved in data exchange.

ditto

· Whether xLink or Key Reference SHOULD be used to reference party, name or address, and the details

ditto

· Whether XML schema SHOULD be extended by using new attributes from a non-target namespace and if so, details of the additional attributes

ditto

· Whether business rules SHOULD be defined to constrain the CIQ XML schemas and if so, details of the business rules that SHOULD be implemented consistently by all applications/systems involved in data exchange."

ditto

These last five paragraphs stump me.

I thought we assigned ValueListURNs to code lists. Why should be specifying xLink or Key Reference?

I'm confused.

Cheers,

Rex

Now --- Did I stir up a hornet's nest??

Respectfully,

Gary A. Ham

http://grandpaham.com

703-899-6241

Grandpa can do IT!

From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Saturday, December 29, 2007 11:39 AM
To: Gary Ham; 'Rex Brooks'; emergency-msg@lists.oasis-open.org
Cc: ejones@warningsystems.com
Subject: RE: Getiing Ready!

Thanks Gary,

Will do.

Cheers,

Rex

At 9:50 AM -0500 12/29/07, Gary Ham wrote:

Folks,

One more typo to correct in the schemas:

In line 3267 - " Provisional" should read "Provisional" ( take out the space after the first quote; it screws our the validation process.)

Gary A. Ham

http://grandpaham.com

703-899-6241

Grandpa can do IT!

From: Gary Ham [mailto:hamgva@cox.net]
Sent: Saturday, December 29, 2007 9:46 AM
To: 'emergency-msg@lists.oasis-open.org'
Cc: 'ejones@warningsystems.com'
Subject: RE: Getiing Ready!

Folks,

I made changes to a copy of the schemas and examples to reduce the number of name spaces from 20 to 2. Basically, there is a namespace for the Common types schema and a namespace for the message reference schema. The message reference schema namespace is reused for all of the separate message types. It works successfully. To put this change in the document requires a 2 line change to each and every schema and example XML file in the document (or you can cut and paste my files into the document in their entirety).

The question is, does this change make sense? The original consensus of the group was that a separate name space made sense for each message. On the other hand, all of the messages use terminology for their tags that is derived from THE SAME REFERENCE SCHEMA. Why should that schema not set the name space for all of its derived messages? So, my suggestion is to make the two line changes. In my mind, it reduces complexity and has a logical basis as well.

I did not try to go to a single namespace for the messages and common types because the types are imported, as opposed to being actually form the same reference source in a restriction sense. It alos keeps them encapsulated, so they could be reused in the future.

Example of the required change is as follows:

In the Commit Resource Message schema:

From:

  targetNamespace="urn:oasis:names:tc:emergency:EDXL:RM:1.0:CommitResource"

To:

    xmlns:rmsg="urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg"

    targetNamespace="urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg"

In the examples:

From:

    xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:RM:1.0:CommitResource EDXL-RMCommitResource.xsd"

    xmlns="urn:oasis:names:tc:emergency:EDXL:RM:1.0:CommitResource"

To:

   xsi:schemaLocation="urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg EDXL-RMCommitResource.xsd"

    xmlns="urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg"

Respectfully,

Gary A. Ham

http://grandpaham.com

703-899-6241

Grandpa can do IT!

--

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

--

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670

emergency-msg message