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