underlying XML support and implementation

[Kralidis,Tom [Burlington]]

(WAS RE: [UMN_MAPSERVER-DEV] request for comment: adding xslt processing
to mapserver)

> Kralidis,Tom [Burlington] wrote:
> > Perhaps the biggest issue this has raised is the need for a 
> discussion 
> > of the future of MapServer XML support (i.e. msIO_printf 
> vs. libxml2).
> > Most of MapServer XML is msIO_printf.  The relatively 
> recent OGC:SOS 
> > and OGC:OWS support is libxml2.  Before any decision on 
> XSLT is made, 
> > I think we need to hash this out.  Comments?
> 
> Tom,
> 
> I'm in favor of moving all XML generation that is not not 
> used for large documents (which I assume is just the WFS 
> GetFeatures request) to libxml2 to ensure correctness of output.
> 

In general, WFS GetFeature and SOS GetObservation requests would be the
operations which would (likely) be the most expensive.

> I don't think it should be done for the GetFeatures since it 
> becomes impractical to return a very large result without 
> using unreasonable machine resources.
>

Actually, GetFeature / GetObservation would be the target use case to do
XSLT prior to output.  Plus, it would depend on the volume of the
response.  Definitely more discussion and caution required here.
 
> But before such an overhaul would go forward we would need 
> someone willing to commit the very substantial amount of time 
> for coding, and more importantly testing to ensure that 
> nothing gets broken.  Given the modest advantages to such a 
> re-working, I'm dubious that someone will come forward that 
> wants to take this and with a willingness to do it right.
> 

I understand.  Can something like this be done in small
chunks/iterations vs. an overhaul?  For example, if I were to
strategize, I would move forward in the following manner:

- WCS (Capabilities, DescribeCoverage)
- WFS (all operations)
- WMS (GetCapabilities, GetFeatureInfo, DescribeLayer, GetStyles)

Obviously, WFS and WMS would need very close attention.

As well, could this be for "future development", i.e. for WFS 1.1.0
support (if/when implemented), the developer would ensure that libxml2
is used and the code is updated.

I've cc'd Assefa who initially implemented mapogcsos.c for any comments
on libxml2 in the context of this thread.

> As a TSC/PSC member, if I had "resources to allocate", this 
> would not top the list of pressing needs.
> 

True.  There are other, more front page items to address.  At the same
time, IMHO, having an underlying libxml2 model would open the doors for
much functionality (and subsequent development/funding) in the world of
information dissemination across the wire in XML.  I think this is
especially timely as the IT world moves towards the "schematic" and
"semantic" aspects of interoperability, so I would expect that this
would be a welcome functionality, for those who desire it.

Personally, I would be willing to commit my time to help with code
review and testing, and updates to mapowscommon.c as a result.

If one of MapServer's key "selling" points is / will be the significant
support of OGC specifications (most of which inherently deal with XML),
I believe this approach will prove worthwhile in the long run.

..Tom