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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

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


Subject: Re: [emergency-comment] Re: EDXL-RM additional issues....?


Thanks DAvid,

I think I can manage that. ;)

Cheers,
Rex

David RR Webber (XML) wrote:
> Rex,
>
> We're certainly right on the tip of that spear with the CAM toolkit 
> for NIEM IEPDs work we are doing!
>
> But I believe we are at a excellent point with that work - we've been 
> able to distill the easy step-by-step guide.
>
> However - the wheels of government turn slowly - so it will probably 
> be after the NIEM conference end of September before we can push this 
> out more broadly to folks.
>
> Just don't chew away your fingers in the meantime... ; -)
>
> Thanks, DW
>
>     -------- Original Message --------
>     Subject: Re: [emergency-comment] Re: EDXL-RM additional issues....?
>     From: Rex Brooks <rexb@starbourne.com>
>     Date: Tue, July 28, 2009 6:09 pm
>     To: "David RR Webber (XML)" <david@drrw.info>
>     Cc: emergency-comment@lists.oasis-open.org, Timothy Grapes
>     <tgrapes@evotecinc.com>, "Gooch,Martena M."
>     <MARTENA.M.GOOCH@saic.com>,
>     emergency-msg@lists.oasis-open.org, hamgva@cox.net, "Gilmore,Timothy"
>     <TIMOTHY.D.GILMORE@saic.com>
>
>     Thanks David,
>
>     The examples actually come from a fairly early draft and we never saw
>     fit to change them because they are meant to be illustrative. I
>     forgot
>     how literal-minded even I am when looking at someone else's
>     example. I
>     grokked what you said right away. This is something we need to
>     remember,
>     and, to be honest, one reason I want to use a structural tool like
>     Enterprise Architect to create the reference implementation
>     simultaneously with the specification. That way we can generate
>     examples
>     directly from the specification. However, I am finding that it almost
>     requires a process-nazi mentality, and that's totally
>     counter-productive. How do you show people the advantage of something
>     that has to be done correctly first? Pioneering is an
>     expletive-deleted!
>
>     Cheers,
>     Rex
>
>     David RR Webber (XML) wrote:
>     > Rex,
>     >
>     > The examples are whacko - but I suspect the XSD schema itself is
>     fine.
>     >
>     > This is in part one issue I'd pointed to with the cross-reference to
>     > NIEM and the dictionary.
>     >
>     > Becuase NIEM "borrowed" liberally from CIQ - without formally using
>     > the schemas - we have items such as Address and PersonFirstName
>     et al
>     > - that show up in EM, XNAL, and NC namespaces - so which one are
>     we using?
>     >
>     > Well it is clear if you look at the schema - but mostly people can't
>     > grok that at the machine level - so have a nice cross-reference
>     > spreadsheet helps human understanding of the mappings.
>     >
>     > Any - back to XML examples in the documentation - the way the
>     EDXL XSD
>     > is constructed - you DO NOT need the namespace prefixes in the XML
>     > instance - because it is ONLY the type reference that uses the
>     > namespace to denote what type definition is used.
>     >
>     > So - <xsd:element name="DavesElement" type="xnal:Organization"
>     > minOccurs="1"/>
>     >
>     > does not mean I have to use xnal:DavesElement - NO! its just
>     > <DavesElement>Example</DavesElement>
>     >
>     > Hope that is clear. If anyone is confused - just use CAM toolkit to
>     > generate you examples! (sourceforge.net - camprocessor for the
>     download)
>     >
>     > However - back to documentation - this should have simple XML
>     > instances in without the namespaces.
>     >
>     > Thanks, DW
>     >
>     > -------- Original Message --------
>     > Subject: [emergency-comment] Re: EDXL-RM additional issues....?
>     > From: Rex Brooks <rexb@starbourne.com>
>     > Date: Tue, July 28, 2009 12:35 pm
>     > To: "Gilmore, Timothy" <TIMOTHY.D.GILMORE@saic.com>
>     > Cc: emergency-comment@lists.oasis-open.org, Timothy Grapes
>     > <tgrapes@evotecinc.com>, "Gooch, Martena M."
>     > <MARTENA.M.GOOCH@saic.com>,
>     > emergency-msg@lists.oasis-open.org, hamgva@cox.net
>     >
>     > Thanks Tim,
>     >
>     > This is not addressed in the pending ECSL-RM Errata since we could
>     > only
>     > address comments which were made to us previously. At this point, I
>     > would not favor taking the time away from working on EDXL SitRep to
>     > focus back on the RM Errata, which we only just got voted out of the
>     > subcommittee for the EM TC decision. at the next EM TC meeting.
>     >
>     > These xml example issues, while they may be a concern, are
>     > non-normative
>     > unlike the broken cross-reference links in the Conformance Section
>     > which
>     > directly affect the ability to check conformance, so might not be
>     > addressed in an Errata, depending on the SC's recommendation to
>     > the TC.
>     >
>     > However, I am asking Gary Ham to take a look at these instances,
>     > adding
>     > him to the addressees as well as including the EM-Msg SC in this
>     > reply.
>     >
>     > Cheers,
>     > Rex
>     >
>     > Gilmore, Timothy wrote:
>     > >
>     > > All,
>     > >
>     > > One of our new software developers came across some EDXL-RM issues
>     > > that I’m not if they have been addressed yet. However, I am
>     > passing
>     > > his information along to get added or noted for feedback and reply.
>     > >
>     > > * For example, there are some inconsistencies in the use of
>     > namespaces
>     > > between the documentation and examples. For importing and
>     > displaying,
>     > > I am ignoring namespaces, since we don't really care as long as the
>     > > XML validates correctly and the actual node name is correct.
>     But for
>     > > producing a new message, it would be nice to be a little more
>     > > definitive, since we don't know how strict a receiving organization
>     > > will be. Part of it may be my limited understanding of namespace
>     > > syntax in an Xml document. For example, There is a LocationType
>     > > element defined on page 127 of the EDLX-RM standard. LocationType
>     > > specifies an Address element of type xal:AddressType. The
>     example on
>     > > page 59 shows it being used in the ScheduleInformation element. The
>     > > syntax is: *
>     > >
>     > > * *
>     > >
>     > > * <rm:Address> *
>     > >
>     > > * <xal:Country></ xal:Country> *
>     > >
>     > > * ... *
>     > >
>     > > * </rm:Address> *
>     > >
>     > > * *
>     > >
>     > > * I assumed that the "rm" was used since <Address> was resource
>     > > metadata for <Location>. But then if you look at page 126 where
>     > > AddressType is used in the <AdditionalContactInformation>
>     > element, it
>     > > uses the syntax: *
>     > >
>     > > * *
>     > >
>     > > * <xal:Address> *
>     > >
>     > > * <xal:Country></ xal:Country> *
>     > >
>     > > * ... *
>     > >
>     > > * </xal:Address> *
>     > >
>     > > * *
>     > >
>     > > * And then if you look further on page 126, the <PartyName> element
>     > > uses the "xnl" namespace, but <Addresses> and <ContactNumbers> use
>     > > "xpil". It states at the top of page 126 that PartyType is in the
>     > > "xpil" namespace, so I don't know if these are typos, or if I just
>     > > don't have a good understanding of how to cascade namespaces. *
>     > >
>     > > * *
>     > >
>     > > * On top of that, some of the example Xml that I downloaded from
>     > their
>     > > website are missing required elements, but have additional elements
>     > > that don't appear in the standard. As for these, I just ignore the
>     > > extra elements, and go strictly by what it says in the standard. *
>     > >
>     > > * *
>     > >
>     > > * Overall, it seems like the documentation is a little immature. *
>     > >
>     > > Thanks,
>     > >
>     > > * Timothy D. Gilmore * | SAIC
>     > >
>     > > Senior Test Engineer | ILPSG | NIMS SC | NIMS STEP
>     > >
>     > > phone: 606.274.2063 | fax: 606.274.2012
>     > >
>     > > mobile: 606.219.7882 | email: gilmoret@us.saic.com
>     > > <mailto:gilmoret@us.saic.com <#Compose> <#Compose>>
>     > >
>     > > P Please consider the environment before printing this email.
>     > >
>     >
>     >
>     > --
>     > Rex Brooks
>     > President, CEO
>     > Starbourne Communications Design
>     > GeoAddress: 1361-A Addison
>     > Berkeley, CA 94702
>     > Tel: 510-898-0670
>     >
>     >
>     > --
>     > This publicly archived list offers a means to provide input to the
>     > OASIS Emergency Management TC.
>     >
>     > In order to verify user consent to the Feedback License terms and
>     > to minimize spam in the list archive, subscription is required
>     > before posting.
>     >
>     > Subscribe: emergency-comment-subscribe@lists.oasis-open.org
>     > Unsubscribe: emergency-comment-unsubscribe@lists.oasis-open.org
>     > List help: emergency-comment-help@lists.oasis-open.org
>     > List archive: http://lists.oasis-open.org/archives/emergency-comment/
>     > Feedback License:
>     > http://www.oasis-open.org/who/ipr/feedback_license.pdf
>     > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>     > Committee:
>     > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency
>     >
>
>
>     -- 
>     Rex Brooks
>     President, CEO
>     Starbourne Communications Design
>     GeoAddress: 1361-A Addison
>     Berkeley, CA 94702
>     Tel: 510-898-0670
>
>
>     -- 
>     This publicly archived list offers a means to provide input to the
>     OASIS Emergency Management TC.
>
>     In order to verify user consent to the Feedback License terms and
>     to minimize spam in the list archive, subscription is required
>     before posting.
>
>     Subscribe: emergency-comment-subscribe@lists.oasis-open.org
>     Unsubscribe: emergency-comment-unsubscribe@lists.oasis-open.org
>     List help: emergency-comment-help@lists.oasis-open.org
>     List archive: http://lists.oasis-open.org/archives/emergency-comment/
>     Feedback License:
>     http://www.oasis-open.org/who/ipr/feedback_license.pdf
>     List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>     Committee:
>     http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency
>


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



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