| Problem | Description |
Solution |
||
|---|---|---|---|---|
| IDREF | HREF | |||
| 1 | Type of Node. | Currently the type of a node is specified using xsi:type either explicitly or via a schema. This may not be the case for the targets of external links. | No change required. | Remove the requirement that all values are typed, possibly adding other means of deriving the xsi:type, e.g. from the resources MIME type. |
| 2 | Dereferencing | When, or if, to attempt to dereference links. | All graph edges are internal to the envelope. Therefore deserialisation MUST/SHOULD dereference all links, any failure MUST generate a fault. | Some graph edges may be external to the envelope. Deserialisation layer MUST/SHOULD dereference internal links, MAY dereference external links and MAY/SHOULD/MUST fault when an link is not dereferenceable. Should the faulting semantics be different for internal and external graph edges ? |
| 3 | Representation of external data in programming languages | Internal data with xsi:type is mapped naturally into programming language types, how about external data? | Not applicable. | The implementation represents binary data in byte arrays or streams, XML data is represented as usual. |
| 4 | Serialising internal vs external links. | During serialisation, the SOAP processor has to decide what to include as internal content and what is left as an external resource. | Not applicable. | Either the SOAP processor has to be told or has to have some ad-hoc rules. |
| 5 | Distinction between internal and external links | The SOAP processor has to be able to work out which links are internal and which are external. | Not applicable. | SOAP processor has to implement logic based on the URI schemes supported. |
| 6 | Full implementation of external link support in core. | If external links are permitted in the encoding then every generic SOAP processor must be able to handle them. | Not applicable, any external links are just node values. | External link support required. |
| 7 | Support for SOAP with attachments | Currently the SOAP with attachments specification uses the href attribute to refer to attachments from within the envelope. | A new higher level construct is required,
e.g. :
<parameter xsi:type="soapatt:att"> i.e. SOAP with attachments support is layered on top of the core encoding. |
No change required |
Only the problem no. 2 requires some added language in case we should choose IDREFs and that language is IMHO crisper and less vague (prone to misinterpretation) than the current text for the href case.
So actually going with hrefs requires us to specify a lot (solving problems 1, 2, 3, 4, 5) and results in more complicated implementation, while going with IDREFs requires us to change/specify a relatively little (2, 7) and the implementation is simplified. By the way, we consider the change to attachments a cleanup change.