[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, 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>> > > > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]