**XML Responses**

Aaron Braeckel

Research Applications Laboratory

NCAR

1)Standardization -- What do you think should be standardized?
(Namespace, schema, WSDL, taxonomy, data dictionary, etc.) (Please
discuss the scope of standardization, level of detail/flexibility, etc.)

> Definitely namespaces and schemas. Complete standardization of the web
> interfaces may be harder, because the services provided by different
> groups are not the same. What about extending or using existing GIS
> standards for these things (WFS, WCS, etc)? I think they offer a good
> example to start from in terms of how to develop a working standard,
> and have had some of the same issues and cover some of the same needs.
>
> Would like to hear discussion on this area, this is a big question.

2)Can you think of any other agencies with a stake in the

development of a METOC XML standard that should be invited to
participate?

> The JPDO Dissemination sub-team is addressing very similar issues. I
> am unsure what the appropriate relationship is between the two groups.
> The FAA SWIM group (which is closely related to the JPDO) is dealing
> with some of these issues as well.

3)What stumbling blocks do you see with the standardization

process and the effectiveness of the new standard?

> I see a tension between ease-of-use (simplicity) and completeness. By
> trying to make a complete standard we make a very large standard that
> is harder to understand and implement. Groups that are interested in
> small pieces of the standard may have a harder time getting things
> done (such as the average web developer). By making a simpler standard
> we don\'t completely standardize the domain. Is there a happy
> middle-ground? An understandable/simple but complete standard? Many of
> the ADDS user base is reformatting our output for their web pages and
> would find it cumbersome to learn a large standard, so whether we need
> to address this type of user group should be considered. Certainly
> simplicity would be a boon in any case.

Chris MacDermaid

1\) Standardization -- What do you think should be standardized?
(Namespace, schema, WSDL, taxonomy, data dictionary, etc.) (Please
discuss the scope of standardization, level of detail/flexibility, etc.)

> It\'s more important that there is a standard than what the standard
> is. When there is a requirement to exchange data in XML with a
> standard we have a way to accomplish that requirement. The standard
> needs to be flexible enough to allow for it to be extended to
> accommodate new meteorological data.

2\) Can you think of any other agencies with a stake in the development
of a METOC XML standard that should be invited to participate?

> The NOAA Data Management Integration Team has a standards subcommittee
> that\'s addressing similar issues. It may be good to have input from
> someone on that subcommittee. I haven\'t spoken to anyone on this
> committee. Two of the committee members are Steve Hankin
> (<steven.c.hankin@noaa.gov>) and Dave McGuirk
> (<david.mcguirk@noaa.gov>).

3\) What stumbling blocks do you see with the standardization process
and the effectiveness of the new standard?

> Developing new standards is a long complicated process. Adopting
> existing standards can be more easily accomplished. If everything that
> is needed is addressed in the METOC standards then there shouldn\'t be
> much of a stumbling block here.
>
> The effectiveness of this will be based on how widely it is used. The
> way I see it being used by my group is for data exchange. We already
> have a requirement to use this starting in November to exchange data
> with AFWA.
>
> From what I can tell the METOC XML scheme is only authorized to be
> distributed to DOD and DOD contractors. Other U.S. requests need to be
> referred to the Commander, Naval Meteorology and Oceanography Command
> and Commander, Air Force Weather Agency. This needs to be made public
> in order for it to be adopted as an international standard.

Marc Touchton

1)  Standardization -- What do you think should be standardized?
    (Namespace, schema, WSDL, taxonomy, data dictionary, etc.) (Please
    discuss the scope of standardization, level of detail/flexibility,
    etc.)

A good starting point would be taxonomy and a data dictionary. All
agencies should refer to the same data type by the same method and have
a common understanding of the exact meaning of the data represented by
taxonomy. In my limited knowledge, it seems a namespace would be the
logical follow-on step.

2)  Can you think of any other agencies with a stake in the development
    of a METOC XML standard that should be invited to participate?

They following agencies are not indicative of involvement in CEISC or
OFCM, they do however represent agencies with no current participation
in the JAG XMLWS. I believe the following agencies would be very much
interested in the development and standardization of a national data
delivery method. Every agency may not be involved in the entire process,
but their particular needs and contributions will need to be included at
various points. After each agency an attempt to list how they would
interact with the national standard is included.

[Users]{.underline}

NASA -- Receiving launch weather (forecast) data and space weather
(current and forecast) data.

FAA -- The big draw for FAA into the XMLWS circle will be the
development and fielding of NGATS

USCG -- Receiving observations and forecasts for units underway.

Department of Homeland Defense -- Receiving all aspects of environmental
data for situational awareness requirements.

Army Corps of Engineers -- Receiving data on hydrology and flooding.

Forestry Service - ?

[Contributors]{.underline}

DTRA -- Providing downwind forecasts, etc.

USGS -- Providing information on earthquake events.

This list intentionally moved beyond the barrier of purely
meteorological and oceanographic data to include all environmental data
that could be of use by other agencies, the Department of Homeland
Defense in particular.

3)  What stumbling blocks do you see with the standardization process
    and the effectiveness of the new standard?

1\. Funding. Funding will be the hardest obstacle to overcome. With the
lack of non-committed funds across all federal agencies, it will be
difficult to provide the resources required in a timely manner to
efficiently develop an overarching standard.

2\. Releasability. At this time I have not received a status on the
intention of releasing JMBL to parties beyond the Department of Defense.

3\. Level of Specification. A XML standard that is too highly specified
will become cumbersome for the general end user to employ effectively.
On the other hand, a standard that is too general in specification will
lead to disparate schemas that are not interchangeable from agency to
agency.

4\. Customer Focus. Each agency that delivers environmental data has
different constraints and pre-existing conditions upon that delivery to
their customers. Some of these constraints include:

> easy of use; bandwidth limits; dedicated pipes; limited pipes; unique
> pipes; desire to reduce impact to customer; fear of alienation;
> financial resources prevent customer adaptation; current methods "good
> enough"; timely delivery; no apparent "benefit"; legacy systems,
> standards, and pipes; stove piping; fear of compromise; etc.

5\. Current Development. Most agencies have begun development of XML and
web services independently of the others and may be reluctant, as they
perceive it, to jump to another horse late in the race.

6\. Lack of official mandate. With no higher level directive requiring
participation or implementation some agencies may only provide token
involvement in the development and immediately decry why the standard
will not work upon delivery.