[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 <email@example.com> > Date: Tue, July 28, 2009 6:09 pm > To: "David RR Webber (XML)" <firstname.lastname@example.org> > Cc: email@example.com, Timothy Grapes > <firstname.lastname@example.org>, "Gooch,Martena M." > <MARTENA.M.GOOCH@saic.com>, > email@example.com, firstname.lastname@example.org, "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 <email@example.com> > > Date: Tue, July 28, 2009 12:35 pm > > To: "Gilmore, Timothy" <TIMOTHY.D.GILMORE@saic.com> > > Cc: firstname.lastname@example.org, Timothy Grapes > > <email@example.com>, "Gooch, Martena M." > > <MARTENA.M.GOOCH@saic.com>, > > firstname.lastname@example.org, email@example.com > > > > 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: firstname.lastname@example.org > > > <mailto:email@example.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: firstname.lastname@example.org > > Unsubscribe: email@example.com > > List help: firstname.lastname@example.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: email@example.com > Unsubscribe: firstname.lastname@example.org > List help: email@example.com > 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