Skip to main content
Hello,

 

 

I have an xml file such as :

 

 

<Content>

 

    <a n="test1">value1</a>

 

    <a n="test2">value2</a>

 

    <a n="test3">value3</a>

 

...

 

</Content>

 

 

i am trying to read this content with an xfmap script ( through an XMLFeatureMapper)

 

I want to create a Feature by "a" element with :

 

- an attribute named "name" -> the value of the attribute "n"

 

- an attribute named "value" ->   the value of the element "a"

 

 

I was hoping to make this like :

 

 

<?xml version="1.0"?>

 

<xfMap>

 

 <feature-map multi-feature-construction="true">

 

    <mapping match="a">

 

       <feature-type> <literal expr="Content"/> </feature-type>

 

    </mapping>

 

 </feature-map>

 

 <feature-content-map>

 

    <mapping match="a">

 

       <attributes>

 

          <attribute>

 

             <name>   <literal expr="NAME"/> </name>

 

             <value>  <extract expr="@n"/>  </value>

 

          </attribute>      

 

       </attributes>

 

    </mapping>

 

    <mapping match="DT">

 

       <attributes>

 

          <attribute>

 

             <name>   <literal expr="VALUE"/> </name>

 

             <value>  <extract expr="."/>  </value>

 

          </attribute>      

 

       </attributes>

 

    </mapping>

 

   

 

 </feature-content-map>          

 

</xfMap>

 

 

Anyone can help ? :)

 

 

Thanks,

 

Julien
Hi,

 

 

is there a particular reason for using xfMaps? I recommend you look into using feature paths instead, it is a lot easier.

 

 

David
Hi,

 

 

Yes feature paths are easier, and in the example you provide the attributes will be returned as a list if you use the content tag as feature type.

 

 

Try this:

 

 

<?xml version="1.0"?>

 

<xfMap>

 

<schema-type>

 

  <inline>

 

    <schema-feature type="a">             

 

    <schema-attribute name='NAME'       type='xml_char(10)' />             

 

    <schema-attribute name='VALUE'     type='xml_char(10)' />             

 

    </schema-feature>

 

  </inline>

 

</schema-type>

 

<feature-map multi-feature-construction="true">

 

<mapping match="a">

 

<feature-type> <literal expr="a"/> </feature-type>

 

<attributes>

 

    <attribute required='true'>

 

    <name>   <literal expr='NAME'/> </name>

 

    <value>  <extract expr='@n'/> </value>

 

    </attribute>

 

    <attribute required='true'>

 

    <name>   <literal expr='VALUE'/> </name>

 

    <value>  <extract expr='.'/> </value>

 

    </attribute>

 

</attributes>        

 

<use-mappings/>                                                        

 

</mapping>

 

</feature-map>

 

</xfMap>

 

 

Itay
Forgot to mention that you have the option of exposing the NAME and VALUE attributes in the XMLFeatureMapper transformer (FME 2014), avoiding an extra AttributeExposer on the canvas.

 

Itay
Hi,

 

 

I agree the "Feature Paths" option is a way which should be considered first. But it doesn't seem that there is the option in the XMLFeatureMapper. If there was no choice other than the XMLFeatureMapper, using xfMap may not be avoided.

 

  Some additional comments. (and correction for typos) -----

 

<?xml version="1.0"?> <xfMap> <!-- "fme_geometry{0}" attribute has to be defined for each "schema-feature". But "schema-type" element is not essential unless needing to configure the schema for a reader feature type. -->     <schema-type>         <inline>             <schema-feature type="Content">                 <schema-attribute name="NAME" type="xml_char(10)" />                 <schema-attribute name="VALUE" type="xml_char(10)" />                 <schema-attribute name="fme_geometry{0}" type="xml_no_geom" />             </schema-feature>         </inline>     </schema-type>

 

<!-- When mapping one feature type only, "multi-feature-construction" attribute can be omitted. It's default value is "false". -->     <feature-map multi-feature-construction="true">         <mapping match="a">             <feature-type>                 <literal expr="Content" />             </feature-type>             <attributes>                 <attribute>                     <name><literal expr="NAME" /></name>                     <value><extract expr="@n" /></value>                 </attribute>                 <attribute>                     <name><literal expr="VALUE" /></name>                     <value><extract expr="." /></value>                 </attribute>             </attributes>         </mapping>     </feature-map> </xfMap> -----

 

 

Takashi

 


Hi Takashi,

 

 

Thank you for adding these valuable comments, however the fme_geometry will allways be non-geometry if no further geometry handling is taking place, and according to the original post, it does look like additional feature types are involved (DT).

 

 

Itay
Hi Itay,

 

 

<schema-type> element seems to be used for configuring reader feature type schema(s) only when adding an XML Reader to workspace. In my trials, even if the data has no geometry, XML Reader cannot be added when the xfMap doesn't contain "fme_geometry{0}" definition for each feature type. Workbench shows this error and fails. ----- Schema feature had no fme_geometry{} members Program Terminating Translation FAILED. -----   Regarding "multi-feature-construction", it depends on contents of the actual data as you mentioned.

 

 

Takashi
Thanks guys, it was very helpful ! 😉
Hi Takashi,

 

 

Yes you are correct, that it is necessary when using an XML reader + xmp, and it will fail without the correct fme_geometry definition.

 

However when using the XMLFeatureMapper, it seems to be possible not to define the fme_geometry.

 

The only reason for defining the schema type, is so that the attributes are immediatly made available.

 

 

Itay
In fact, it's not always necessary to define <schema-type> element explicitly. Even if <schema-type> element was lacked,  XML Reader can be added and also the XMLFeatureMapper works fine. When there isn't <schema-type> element, FME works with default mode. i.e. <schema-type><scan /></schema-type> I recognize <schema-type>(<inline> mode) should be defined when attribute types have to be defined explicitly for the reader feature type(s).

Reply