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,

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]