Stream: implementers
Topic: Composition.section as a datatype
Rick Geimer (May 10 2017 at 05:36):
Hi all. Structured Documents is considering modifying the Composition resource such that Composition.section would become it's own datatype, much like the Dosage datatype. This would allow the creation of reusable section profiles that could be reused consistently across different document types. Before we decide to make that change though, we wanted to gather feedback from implementers to see if anyone could think of major issues with this approach. This should not be a breaking change for existing Composition instances, but definitely has implications for profiling tools.
Grahame Grieve (May 10 2017 at 08:54):
most of us who maintain profile tooling have already thought about this here, and are in favour of it.
Michel Rutten (May 10 2017 at 10:10):
Actually, I think an external datatype is easier to implement.
Richard Townley-O'Neill (May 10 2017 at 22:51):
Why make section a datatype, and not a resource like list? Are some of the Resource and DomainResource attributes a problem?
Richard Townley-O'Neill (May 10 2017 at 22:54):
Is it because a DataType can easily substitute for a BackboneElement, but a Resoure cannot?
Lloyd McKenzie (May 11 2017 at 05:21):
Resources have their own status, identity and can live and be maintained independently. There's no ineritance between resources. In practice, sections are generally authored in the context of a specific document and you need all of the context elements present on Composition for a section to make sense.
Lloyd McKenzie (May 11 2017 at 05:21):
That doesn't mean we couldn't make Section a resource, but we'd need to think very carefully about the impact of making it "stand-alone" and whether that reflects how document-authoring systems actually behave.
Grahame Grieve (May 11 2017 at 06:42):
that would create a lot of problems
Mark Kramer (May 11 2017 at 11:30):
Doesn't the problem lie with the use of backbone element itself? Since the backbone isn't a datatype subject to profiling, we can't slice section.
Grahame Grieve (May 11 2017 at 11:51):
well, one solution is to allow profiling to start inside a resource, not only at the root. That's complexity I didn't want to have, and this avoids that
Mark Kramer (May 11 2017 at 11:52):
One man's complexity is another man's parsimonious reuse.
Mark Kramer (May 11 2017 at 11:53):
The lack of typing associated with backbone elements actually causes some problems in the solution I showed you yesterday.
Grahame Grieve (May 11 2017 at 11:53):
well, tell me more about that
Mark Kramer (May 11 2017 at 11:54):
It gets very technical, and @Chris Moesel would be better able to explain the details.
Grahame Grieve (May 11 2017 at 11:54):
ok
Last updated: Apr 12 2022 at 19:14 UTC
