# TDS (and TDD) implementations?

**URL:** <https://discourse.openehr.org/t/tds-and-tdd-implementations/15244>\
**Category:** Technical (archive)\
**Created:** [30 May 2013 09:21 UTC](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244 "2013-05-30T09:21:12Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [14 June 2013 14:48 UTC](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244/21 "2013-06-14T14:48:41Z")

</div>

Compact serialization?

When nodes in the archetype while they are developed and can change in the ‘template’ level or even during run-time,  
there never will be a simple serialization to an XML/XDS format. To much is volatile.

When you say ’ more compact serialization formats’  
do you mean shorter XML payload that go ver the wire?

Observe that when parties decide to be semantically interoperable this means that every data point and all its context needs to be sent over the wire.  
Full semantic interoperability demands more resources than just updating fields in a database.

Gerard Freriks  
+31 620347088  
[gfrer@luna.nl](mailto:gfrer@luna.nl)

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [14 June 2013 14:50 UTC](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244/22 "2013-06-14T14:50:41Z")

</div>

One simple example:  
I can have an archetype slot that is filled at run-time as allowed by a regular expression or a hand entered list of possible archetypes that can fill that slot.  
But there are more examples.

Gerard Freriks  
+31 620347088  
[gfrer@luna.nl](mailto:gfrer@luna.nl)

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [14 June 2013 14:54 UTC](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244/23 "2013-06-14T14:54:15Z")

</div>

The best example is:  
One ENTRY archetype node that can have one ore more Clusters added to it - when allowed -of course-via Archetype slots at run- or design time.

Gerard Freriks  
+31 620347088  
[gfrer@luna.nl](mailto:gfrer@luna.nl)

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [14 June 2013 15:08 UTC](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244/24 "2013-06-14T15:08:18Z")

</div>

actually it would not even be all that hard. It is just a case of doing a data-level transform that corresponds to the reverse of the current TDS generator. It would need access to the templates and archetypes, that's all.

- thomas

[Previous page](https://discourse.openehr.org/t/tds-and-tdd-implementations/15244.md?page=1)