Kepler

I dug around and found the xml instance is:
<karEntryAttributes>
<Name>
tpc09-plant-dynamics-woody_ROML.xml
</Name>
<dependsOn>
urn:lsid:gamma.msi.ucsb.edu/OpenAuth/:8016:19:1
</dependsOn>
<handler>
org.kepler.kar.handlers.ReportLayoutKAREntryHandler
</handler>
<dependsOnModule>
reporting
</dependsOnModule>
<lsid>
urn:lsid:gamma.msi.ucsb.edu/OpenAuth/:3371:205:1
</lsid>
<type>
org.kepler.reporting.rio.ReportInstance
</type>
</karEntryAttributes>

The schema is:
<xs:complexType name="karEntryAttributesType">
<xs:sequence>
<xs:element name ="Name" type="xs:string" />
<xs:element name ="dependsOn" minOccurs="0" />
<xs:element name ="dependsOnModule" minOccurs="0" />
<xs:element name ="handler" />
<xs:element name ="lsid" />
<xs:element name ="type" />
</xs:sequence>
</xs:complexType>

Their orders are not match. So my question is: is the order of the schema correct?
If the schema is correct, we can change the code to create instance. Otherwise, we have to change the schema.

whichever is less of a headache to change. we are in charge of both of them, so you might as well make it easy for yourself!

Also - for WRP we are going to be adding more children to <karEntryAttributes> - ideally we'd like to add any element (as a string) since we are just transferring the manifest information to the XML.
it might be worthwhile to relax this element to allow as many child elements as we want for karEntryAttributes.
Or we could just wait for and change it when we get the WRP release ready

hrrm, this is a good point that wrp will add more elements there. I think the wrp will release soon. I don't want to upgrade the schema so frequently. We need to figure out the flexible way in the schema.

I dug code a little bit and found here is the code to generate the elements of karEntryAttribute:

Attributes atts = entry.getAttributes();

for (Object att : atts.keySet()) {

if (att instanceof Name) {

Name attrName = (Name) att;
     String value = atts.getValue(attrName);
     karxml.append(tab + tab + tab + "<" + attrName + ">" + nl);
     karxml.append(tab + tab + tab + tab + value + nl);
     karxml.append(tab + tab + tab + "</" + attrName + ">" + nl);

}

Attribute class extends from Map class. The Set object generated by atts.keySet() method doesn't have a fixed order. So the xml elements' order will vary too (this means that the xml instance could be invalid).

We will use a ordered key list (elements name) to get the value from the map. Then build the xml base on the element name and value. So the order of element will be same.

Will this support the addition of more attributes in the future?

Sean: yes it will support new attributes too:

Ben, Aaron and I discussed the possibility to add some arbitrary elements to karEntryAttributes. We decided to modify the schema:
<xs:complexType name="karEntryType">
<xs:sequence>
<xs:element name="karEntryAttributes" type="karEntryAttributesType"/>
<xs:element name="karEntryXML" type="xs:anyType" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="karEntryAttributesType">
<xs:sequence>
<xs:element name ="Name" type="xs:string" />
<xs:element name ="dependsOn" minOccurs="0" />
<xs:element name ="dependsOnModule" minOccurs="0" />
<xs:element name ="handler" />
<xs:element name ="lsid" />
<xs:element name ="type" />
<xs:element name="customAttribute" type="xs:anyType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>

This schema still has some control on some elements (name, lsid and et al), it also has the flexibility to add arbitrary elements under element customAttribute.

If you have any objection, please let me know as soon as possible.

Here is an email from Aaron:

Hi Jing, I was thinking about this a bit and I think option 1 is the way to go. The KAREntryHandler mechanism allows any attribute
to be added to a KAREntry so the KARXML file will reflect that and should validate when it does. Since the required attributes like
lsid are enforced in the KARFile mechanism it is OK not to enforce it in the schema but we still need to allow any attribute to exist
there. A new KAREntryHandler that is developed with a new module may want to add an attribute that is not in the option 2 schema and
the developer shouldn't need to know about the customAttribute to add attributes to the Manifest (and by consequence the KARXML). So
I'd recommend option 1 for best compatibility if I'm understanding the schema correctly.

Aaron

Since Aaron is the person who is working on this part, i will go with option 1:

<xs:complexType name="karEntryType">
<xs:sequence>
<xs:element name="karEntryAttributes" type="xs:anyType"/>
<xs:element name="karEntryXML" type="xs:anyType" />
</xs:sequence>
</xs:complexType>

After changing the schema base on comment 9, the invalid error has gone.

Original Bugzilla ID was 4942