Issue with XML
Posted by mdalby on 2008-10-13 18:27
I emailed Michal Young last night regarding our issue with the ambiguous XML. Below is my email and his response. For those of you that don't know about this issue (and still care), read my message to him.
***********************************
I suspect this is an indication that the GIS data is not entirely self-describing. And what that probably means is that some additional user guidance is going to be needed. What's an "assumption" in the old code probably needs to become something like a "parameter" for the new code ... whether that means having some kind of configuration file or something else, I don't know.
I don't think surface type is actually used in the current map, so in this particular case it might not even matter ... but if there is one case like this, I won't be surprised if there are others.
--Michal
On Oct 12, 2008, at 10:57 PM, Michael Dalby wrote:
> Hey Michal, we at the Ramani group have something we'd like to run by you:
>
> We're working on generalizing the XML. However, we've come across an
> interesting issue. While looking at the GIS XML data, we noticed that
> some of the XML was ambiguous. For example, we found these lines used in
> the Athletic Surfaces file:
>
> <Value xsi:type="xs:string">rubber</Value>
> <Value xsi:type="xs:string">High Jump Apron</Value>
>
> The Red teams XSLT transformation interprets the first value to be the
> surface type, and the second to the name of the object. However, these
> are assumptions we make based on the UO map data. Not all of the layers
> use this standard. Furthermore, we couldn't find this in the ArcGIS 9.2
> XML Schema. We presume this came from the person who set up the data
> adding information in manually. The impact of this is that if we
> generalize the XML parser, we will lose information (surface type and
> name in this case) because we are no longer making assumptions about
> what the XML means in ambiguous cases. Normally we would try to resolve
> this issue on our own, however we cannot interface with the person
> entering the GIS data to consult them. Do you have any advice or
> comments for us on this topic?
>
> Thank you.
> Sincerely
> Michael Dalby
> Ramani Map
***********************************
I suspect this is an indication that the GIS data is not entirely self-describing. And what that probably means is that some additional user guidance is going to be needed. What's an "assumption" in the old code probably needs to become something like a "parameter" for the new code ... whether that means having some kind of configuration file or something else, I don't know.
I don't think surface type is actually used in the current map, so in this particular case it might not even matter ... but if there is one case like this, I won't be surprised if there are others.
--Michal
On Oct 12, 2008, at 10:57 PM, Michael Dalby wrote:
> Hey Michal, we at the Ramani group have something we'd like to run by you:
>
> We're working on generalizing the XML. However, we've come across an
> interesting issue. While looking at the GIS XML data, we noticed that
> some of the XML was ambiguous. For example, we found these lines used in
> the Athletic Surfaces file:
>
> <Value xsi:type="xs:string">rubber</Value>
> <Value xsi:type="xs:string">High Jump Apron</Value>
>
> The Red teams XSLT transformation interprets the first value to be the
> surface type, and the second to the name of the object. However, these
> are assumptions we make based on the UO map data. Not all of the layers
> use this standard. Furthermore, we couldn't find this in the ArcGIS 9.2
> XML Schema. We presume this came from the person who set up the data
> adding information in manually. The impact of this is that if we
> generalize the XML parser, we will lose information (surface type and
> name in this case) because we are no longer making assumptions about
> what the XML means in ambiguous cases. Normally we would try to resolve
> this issue on our own, however we cannot interface with the person
> entering the GIS data to consult them. Do you have any advice or
> comments for us on this topic?
>
> Thank you.
> Sincerely
> Michael Dalby
> Ramani Map
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Ramani map is powered by Assembla.
0 Comments