NodeNodeList Reversed in Autogenerated records

Is it just me, or has anyone noticed that when you create a new record in IS from an XML Schema, some of the things that should be lists are not, and some of the things that should be single-valued are lists? I’ve seen this with Records/RecordLists and Strings/StringLists after creating records from a schema we’re using here. Any ideas would be appreciated, since it can be quite annoying to have to change all of these manually.

Be careful about this. I had the same encounter but it was my point of view of what should be repeating that was wrong, not the generated record. Can you post an example?

Yeah, :slight_smile: I was a bit worried about that as well. I even re-read the descriptions of theses types in the docs to be sure. But I certainly do have an example. Here’s an excerpt from my schema(s) that defines an element named “Operation” and it’s children.

<xs:element name=“Operation”>
xs:complexType
xs:choice
<xs:element ref=“Parameters”/>
<xs:any namespace="##other" processContents=“strict”/>
</xs:choice>
</xs:complexType>
</xs:element>

<xs:element name=“Parameters”>
xs:complexType
xs:sequence
<xs:element ref=“Parameter” maxOccurs=“unbounded”/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name=“Parameter”>
xs:complexType
xs:sequence
<xs:element ref=“Value” maxOccurs=“unbounded”/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name=“Value”>
xs:complexType
<xs:attribute name=“Position” type=“xs:positiveInteger” use=“optional”/>
</xs:complexType>
</xs:element>

Now I would think that the “Operation” element would be a Record, and IS agrees. I would also think however, that “Parameters” would be a RecordList, since it contains multiple “Parameter” records (elements). In this case IS makes Parameters a Record.

Also note that the “Value” element (by default) merely contains a string. IS makes this a RecordList. Maybe I should have explicitly declared xs:simpleContent here, but the result is the same.

So, is it me? :slight_smile:

It’s you! :wink: This is indeed the same axle I was wound around.

Parameters contains multiple Parameter entries. Parameter repeats, not Parameters. Think of it in XML terms:

<Parameters> 
  <Parameter> 
     <Value Position="0">xyz</Value> 
     <Value Position="1">abc</Value> 
  </Parameter> 
  <Parameter> 
     <Value Position="0">123</Value> 
     <Value Position="1">456</Value> 
  </Parameter> 
</Parameters>

If you want to restrict Value to one occurrence, change maxOccurs to “1” in the Parameter def.

HTH

Well …

It seems to me that the type of a thing is determined by what it contains, no? So the fact that “Parameter” repeats is what makes me think “Parameters” should be a RecordList. Parameter is a Record (well, actually another RecordList) and there’s a list of them inside of Parameters, ergo Parameters is a RecordList.

Similarly, I do want multiple Value elements inside “Parameter”, and it is this fact that makes “Parameter” a RecordList as well. But Value only contains a single string (and an attribute string), therefore it should be a Record, not a RecordList.

Whether it is a list or not is determined not by what it contains but by the maxOccurs entry of the parent element. The default is 1. Operation says it can have one Parameters entry. Parameters says it can have a list of Parameter entries. Parameters in this case contains a list, it isn’t one itself. If you change

<xs:element ref=“Parameters”/>
to
<xs:element ref=“Parameters” maxOccurs=“unbounded”/> 
you’ll see that Developer will create a list on import.

The way that Parameters is defined in the posted schema snippet, Parameters is a record, not a record list. It’s whether the item itself repeats, not whether its children repeat.

I know it seems a bit strange and backwards. I have trouble keeping it straight sometimes. The way that always straightens it out in my head is thinking about which tags repeat and which do not. Tags that repeat are the lists.

OK, we just have different understandings of the meaning of the word “list”. :slight_smile: I’ll try to keep this in mind as I see more usage examples and maybe it’ll hit me.

The issue behind this however, is that I’m using bizdocToRecord to create a record from an XML doc I submit to TN. Not coincidentally, the doc contains an operation element with a Parameters element that contains 13 Parameter elements. After bizdocToRecord creates the boundNode for me I only have one Parameter entry inside of Parameters. So I get something like:

Parameters
Parameter[0]
Position=13

I thought this was due to the fact the Parameters was defined as a Record, but after changing it to a RecordList and trying again I still only get the last element in my boundNode. Any ideas what I’m doing wrong? Thanks for all your help.

After some off-line work with Rob, I’ve discovered a few things that may be of interest, so I thought I’d share :-). First of all, with this whole Record/RecordList issue - the trick I was missing is that a RecordList is actually an array of records of the SAME TYPE as the list node. So, a node Foo that’s declared to be a RecordList looks like:

Foo
Foo[0]
Foo[1]
Foo[2]

I was under the impression that a RecordList could contain any list of Records, such that a node Foo declared to be a RecordList could look like:

Foo
Bar[0]
Bar[1]
Bar[2]

so long as Bar was a Record. … Because then the RecordList (Foo) would contain a list of Records (Bar). Silly me.

In the midst of all this I also discovered a potential issue with mapping multiple nested records from an input document. The issue seems to be related to either how the records (and their schemas) were created or how the namespaces are specified in the input. We’re still investigating this one however, so I’ll hold off on further discussion of it until we know more.