In several projects we had (and have) to create workarounds, some small some major, for the limited (modern) xml support in Uniface. Specially when it comes to defining complex XML stream and dealing with them (f.i. used in SOAP messages) the DTD is far too limited. At this moment we're building our own web front-end (presentation purposes only) and communicate with it using xml-schema definitions and data streams based on this. In our effort the goal is to generate a 'modern' XML stream where the data is supplied by Uniface using collection and occurrence operations. To be able to reconnect a disconnected recordset, using the reconnect statement, we need to generated some attributes within the data elements: id cannot be manipulated at this moment, only 'set' by xmlsave and 'get' by xmlload using a DTD occcrc can be set/get by using $occcrc status can be set/get by using $occstatus valerr can be manipulated through $occproperties / $fieldproperties If a $occid is provided with set functionality we can send a stream that meets all the terms for using the reconnect statement later in the process. When we receive such a stream stream in Uniface it is obvious that we're not able to use the 'standard' xmlsave routine. We have to define our own parser. Uniface provides an excelent method for this purpose: the UXMLREADER from which we can activate our own collection and occurrence operations. In these operations we have to handle the attributes as listed above. The only attribute we cannot handle is the 'id' attribute. Due to the fact that we're not able to get/set the 'id' attribute we cannot use the reconnect statement and all the goodies that comes with it.
"variable = $occid $occid = value an example [occurrence operation trigger] partner operation decodeStream params xmlstream pStream : INOUT endparams pStream = ""%%pStream%%%
If $occid is available the community is able to handle xml streams besides the uniface way but still be able to use the Uniface backend strength (reconnect statement) and not decrease functionality ... actually I see a gain in functionality because workarounds might be prevented