From Laura.Sato at cfh.nhs.uk Thu Jul 6 14:39:05 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Thu, 6 Jul 2006 14:39:05 +0100 Subject: [New-ITS] request for clinical data analyses and instance examples Message-ID: <1A3D105C334EAE49BDDD93D8767573F503F1F2C0@EXCHAQ2.nhsia.nhs.uk> Hello, As we are beginning to prepare for 'new ITS' proof of concept testing, we have found that we are in desperate need of realistic and clinically complex requirements analysis (information class) models and instance data examples for messaging. Is there anyone 'out there' who might be able to contribute some interesting test cases for running through various options for a new ITS? Anonymised real data would be great, if possible. We would be grateful for any contributions as, at the moment, all we have are the example data published in the NHS MIM to date. Best regards, Laura ________________________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile : (44) (0)7733 324338 Email: laura.sato at cfh.nhs.uk Web: www.connectingforhealth.nhs.uk This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060706/ea4dda69/attachment.htm From ann.wrightson at bt.com Wed Jul 12 13:55:22 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 12 Jul 2006 13:55:22 +0100 Subject: [New-ITS] Some reference material on XML Naming & Design Rules Message-ID: <849288029444F74899F8C8E3D479FF6D94331D@E03MVZ3-UKDY.domain1.systemhost.net> The attached zip contains the UK egovt eGIF Schema Guidelines (that I co-authored) - it's aimed in particular at new adopters of XML-based interoperability. Then I suggest you go to http://xml.coverpages.org/ndr.html for a broader review of the space - & then tackle any of the detailed specs referenced there at your leisure. Ann W. -------------- next part -------------- A non-text attachment was scrubbed... Name: eGIF schema-guidelines-3_1(1).zip Type: application/x-zip-compressed Size: 295882 bytes Desc: eGIF schema-guidelines-3_1(1).zip Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060712/5e22f0df/eGIFschema-guidelines-3_11-0001.bin From Laura.Sato at cfh.nhs.uk Thu Jul 13 12:49:48 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Thu, 13 Jul 2006 12:49:48 +0100 Subject: [New-ITS] NHS project update Message-ID: <1A3D105C334EAE49BDDD93D8767573F503F984D5@EXCHAQ2.nhsia.nhs.uk> Attached are zipped slides that summarise the objectives and approach in the 'New ITS' investigations decided by the NHS project team last week. Principle investigation 'threads' have been characterised as 5 'key questions'. Each of the key questions has been assigned a lead - feel free to contact the leads if particularly interested in a line of enquiry. Updates from all investigations will be sent to this list when available. <> Best regards, Laura ________________________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile : (44) (0)7733 324338 Email: laura.sato at cfh.nhs.uk Web: www.connectingforhealth.nhs.uk This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060713/d589e786/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: ITS-Update_2006-07-13.zip Type: application/x-zip-compressed Size: 6878 bytes Desc: ITS-Update_2006-07-13.zip Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060713/d589e786/ITS-Update_2006-07-13.bin From ann.wrightson at bt.com Tue Jul 18 14:57:46 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 18 Jul 2006 14:57:46 +0100 Subject: [New-ITS] XML design principles Message-ID: <849288029444F74899F8C8E3D479FF6DA1F69C@E03MVZ3-UKDY.domain1.systemhost.net> Some food for thought: 1. The "Guiding principles" section of the UN/CEFACT XML Naming and Design Rules specification includes the following: 258 * Interchange and Application Use - UN/CEFACT XSD Schema and instance documents are 259 intended for business-to-business and application-to-application use. 260 * Tool Use and Support - The design of UN/CEFACT XSD Schema will not make any assumptions 261 about sophisticated tools for creation, management, storage, or presentation being available. 262 * Legibility - UN/CEFACT XML instance documents should be intuitive and reasonably clear in the 263 context for which they are designed. 264 * Schema Features - The design of UN/CEFACT XSD Schema should use the most commonly 265 supported features of W3C XSD Schema. 2. For reference, here are the desgn principles for the first XML ITS, as listed on the HL7 wiki: * The transform from the abstract model to the instance should be as simple as possible. * The instances should be pleasing to the eye of a human reader. * Names should be determined in the abstract model, not generated by the ITS * Without compromising the simplicity of the model-instance transform the instances should be as small as possible. Thus XML attributes were used for datatype components. * The ITS should define the set of valid instances for a V3 artefact, NOT the schema that must be used. This is to allow for stability of the instances as schema techology improves, and also allows for the use of different schema for different uses. (see below) * The ITS should allow for the use of W3C schema for validation and message description. * Use attributes to support the population of PSVI (http://en.wikipedia.org/wiki/PSVI). * CMET references and Wrapper boundaries should be transparent in the instance. Thus it should be possible to re-package the way that an interaction is defined by mergeing two wrappers, without that affecting the instances. (see below) * Choices should be transparent in the instance - thus a class should appear in the instance in the same form whether or not it is part of a choice. This is to allow for forwards compatability when choices are introduced into models and to reduce the level of nesting 3. Here are the suggested principles I presented at the last face-to-face meeting; the key technical principle that puts usability of the XML as XML in what is IMO its proper place is highlighted: Usability and Integrity Principles for XML in a new ITS Usability principles: * Instances are easy to read for a developer with non-specialist UML & XML skills, using the model-stack as a reference (as far as the DAM) * Element names are simple and reflect appropriate domain concepts in a way that is helpful to a human reader, with precision provided by coding. * Element names should conform to generally accepted XML-domain principles for naming, for example, element names should not show the parentage of the element. The development of "Naming and Design Rules" documentation for the XML layer is recommended, as an artefact type well known in the broader XML community. * Instance structure is designed for ease of XML processing (including schema-validation, transformation, storage and retrieval) * A specific interoperability interface can be developed within the XML layer, with design-time reference to the underlying message models * When message components are reused across message types, there should be corresponding XML instance components, where "corresponding" means "can be processed in the same way by common XML tools" (suitable invariants needed) * Priority should be given to supplying schemas that are designed for efficiency of common XML-technology functions such as instance validation, code generation, and data mapping for local integration[1] . * Provided XML schemas should give priority to structural and allowed data content validation over validation of business semantics; if provided, the latter may be added in a modular, phased manner for use where required. Integrity principles: * The content of an XML instance is fully traceable back (to the relevant DAM and thence) to the RIM. It should be possible to generate the XML from the UML using simple straightforward rules. * An instance of a message model is able to be populated fully using an XML instance plus a static model of the message type. * Names of elements and attributes should be determined from the underlying model(s), not generated by the ITS. XML technical principles: * The ITS should define the set of valid instances for a V3 artefact, not the schema that must be used. This is to allow for stability of the instances as schema technology improves, and also allows for the use of different schemas for different uses. * The transform from an instance of the proximal underlying model to the XML instance should be as simple as possible, without compromising the readability and ease of processing of the XML. * The ITS allows for the use of W3C schema for validation and message description, and may support the population of PSVI. * The ITS allows for the use of other schema technologies such as the ISO DSDL family. Ann Wrightson, Martin Bryan & Jay Cousins, July 2006 ________________________________ [1] The existing ITS could be retained and developed further as a separate design-time utility for semantic tracking, model design checking etc) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060718/04aa7e4c/attachment.htm From grahame at kestral.com.au Tue Jul 18 16:27:07 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 01:27:07 +1000 Subject: [New-ITS] Schemas for Validation?? Message-ID: <44BCFDCB.3010103@kestral.com.au> hi I'm reading Ann's xml principles. I will comment on them. but for now, a simple question. Why do we want schemas for validation? Personally, I've always found them frustrating. it seems that we want schemas cause that's all we have, yet they are a poor mans tool... What, say, I wrote a java validation tool for the new ITS, that worked off the MIF and XML source directly, and released it under open source. pro's: * MUCH better error messages * much more thorough validation * faster * more usable * one source of truth con's: ? I can think of a few, but interested in comments and analysis If we had an open source java library/application like that, would we still want schemas for validation? Grahame From rik.smithies at cfh.nhs.uk Tue Jul 18 16:40:37 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Tue, 18 Jul 2006 16:40:37 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <1A3D105C334EAE49BDDD93D8767573F504004BCD@EXCHAQ2.nhsia.nhs.uk> Hi, my thoughts, no particular order : There is a need/wish for CFH to distribute a machine readable spec that suppliers can check their messages against. Traditionally only schema has been available as such a tool. Nowadays you could say that MIF fulfills the same role, but suppliers aren't used to working with MIF, and it's still a moving target. A supplier may choose to ignore such a spec and write their own validation, but not all will, so something everyone can understand is wanted. If everyone was using such an open source validator, and CFH could easily distribute rules for such a thing, then that would do it in theory. But I think that some people like schemas, even if they don't use them in all stages of development. Schemas have historically not been great validators, but CFH work is improving on that, and there is still more that can be done. Schemas are about as widely adopted and understood as anything, even if known to be imperfect. People are suspicious of new tools, more to learn, what if its is buggy, not maintained, not on my platform, open source means I may have to look at source, don't want lock in etc. Schemas can be used for PSVI working. I have done this in last few days for my own purposes, running "simplified" messages into a viewing tool that doesn't support them, by mangling the schemas to "de-simplify" the messages on the fly. cheers, Rik > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 18 July 2006 16:27 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] Schemas for Validation?? > > hi > > I'm reading Ann's xml principles. I will comment on them. > but for now, a simple question. Why do we want schemas for > validation? Personally, I've always found them frustrating. > it seems that we want schemas cause that's all we have, yet > they are a poor mans tool... > > What, say, I wrote a java validation tool for the new ITS, > that worked off the MIF and XML source directly, and released > it under open source. > > pro's: > * MUCH better error messages > * much more thorough validation > * faster > * more usable > * one source of truth > > con's: > ? I can think of a few, but interested in comments and analysis > > If we had an open source java library/application like that, > would we still want schemas for validation? > > Grahame > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. From Charlie at ramseysystems.co.uk Tue Jul 18 16:48:27 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Tue, 18 Jul 2006 16:48:27 +0100 Subject: [New-ITS] XML design principles Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB5B@ramseysc1420.RamseyNet.local> Ann So comments in blue on your principles -- I have been working through the schema guidelines and XML design rules documents that you provided - and have started putting some rough notes on the wiki. all the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay ________________________________ From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of ann.wrightson at bt.com Sent: 18 July 2006 14:58 To: new-its at lists.hl7.org.uk Subject: [New-ITS] XML design principles Some food for thought: 1. The "Guiding principles" section of the UN/CEFACT XML Naming and Design Rules specification includes the following: 258 * Interchange and Application Use - UN/CEFACT XSD Schema and instance documents are 259 intended for business-to-business and application-to-application use. 260 * Tool Use and Support - The design of UN/CEFACT XSD Schema will not make any assumptions 261 about sophisticated tools for creation, management, storage, or presentation being available. 262 * Legibility - UN/CEFACT XML instance documents should be intuitive and reasonably clear in the 263 context for which they are designed. 264 * Schema Features - The design of UN/CEFACT XSD Schema should use the most commonly 265 supported features of W3C XSD Schema. 2. For reference, here are the desgn principles for the first XML ITS, as listed on the HL7 wiki: * The transform from the abstract model to the instance should be as simple as possible. * The instances should be pleasing to the eye of a human reader. * Names should be determined in the abstract model, not generated by the ITS * Without compromising the simplicity of the model-instance transform the instances should be as small as possible. Thus XML attributes were used for datatype components. * The ITS should define the set of valid instances for a V3 artefact, NOT the schema that must be used. This is to allow for stability of the instances as schema techology improves, and also allows for the use of different schema for different uses. (see below) * The ITS should allow for the use of W3C schema for validation and message description. * Use attributes to support the population of PSVI (http://en.wikipedia.org/wiki/PSVI). * CMET references and Wrapper boundaries should be transparent in the instance. Thus it should be possible to re-package the way that an interaction is defined by mergeing two wrappers, without that affecting the instances. (see below) * Choices should be transparent in the instance - thus a class should appear in the instance in the same form whether or not it is part of a choice. This is to allow for forwards compatability when choices are introduced into models and to reduce the level of nesting 3. Here are the suggested principles I presented at the last face-to-face meeting; the key technical principle that puts usability of the XML as XML in what is IMO its proper place is highlighted: Usability and Integrity Principles for XML in a new ITS Usability principles: * useful as an overall test criteriaInstances are easy to read for a developer with non-specialist UML & XML skills, using the model-stack as a reference (as far as the DAM) * criteria for implementable model Element names are simple and reflect appropriate domain concepts in a way that is helpful to a human reader, with precision provided by coding. * Naming rules should be set for the implementable model, but a "Naming and Design Rules" document would be useful for validating the output XML specifications. Element names should conform to generally accepted XML-domain principles for naming, for example, element names should not show the parentage of the element. The development of "Naming and Design Rules" documentation for the XML layer is recommended, as an artefact type well known in the broader XML community. * Instance structure is designed for ease of XML processing (including schema-validation, transformation, storage and retrieval) which means short xPaths, tight schemas, small size, what else? * A specific interoperability interface can be developed within the XML layer, with design-time reference to the underlying message models not clear what this means * When message components are reused across message types, there should be corresponding XML instance components, where "corresponding" means "can be processed in the same way by common XML tools" (suitable invariants needed) * Priority should be given to supplying schemas that are designed for efficiency of common XML-technology functions such as instance validation, code generation, and data mapping for local integration[1] . This requirement has an impact on the definition of the instances (which is fine) * Provided XML schemas should give priority to structural and allowed data content validation over validation of business semantics; if provided, the latter may be added in a modular, phased manner for use where required. the distinction between data content and business semantics would need to be established in the abstract design for this to be robustly followed Integrity principles: * The content of an XML instance is fully traceable back (to the relevant DAM and thence ) to the RIM. It should be possible to generate the XML from the UML using simple straightforward rules. one does not go from the xml to the dam to the RIM -- I suggest that the content must be traceable to both the DAM and the RIM. * An instance of a message model is able to be populated fully using an XML instance plus a static model of the message type. * Names of elements and attributes should be determined from the underlying model(s), not generated by the ITS. XML technical principles: * The ITS should define the set of valid instances for a V3 artefact, not the schema that must be used. This is to allow for stability of the instances as schema technology improves, and also allows for the use of different schemas for different uses. It mayt be reasonable to follow the lead of CDA, and provide a set of schemas to which conformance is required (though the schemas tehmselves do not have to be used). This addresses the appetite for standard schemas, without compromising the freedom to use other schemas or none in a particular implementation. * The transform from an instance of the proximal underlying model to the XML instance should be as simple as possible, without compromising the readability and ease of processing of the XML. This does not indicate what can be done at the ITS level to protect readability and ease of processing. * The ITS allows for the use of W3C schema for validation and message description, and may support the population of PSVI. * The ITS allows for the use of other schema technologies such as the ISO DSDL family. Ann Wrightson, Martin Bryan & Jay Cousins, July 2006 ________________________________ [1] The existing ITS could be retained and developed further as a separate design-time utility for semantic tracking, model design checking etc) I do not see many folk wanting a separate ITS just for these uses -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060718/d56af11a/attachment.htm From Charlie at ramseysystems.co.uk Tue Jul 18 16:57:13 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Tue, 18 Jul 2006 16:57:13 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB5C@ramseysc1420.RamseyNet.local> Grahame I think that the requirement for XML that can be defined using simple schema constructs for structural validation is consistent with the requirement that the XML be processable simply with other technology. I agree that to do rich validation including terminology etc there will be a need to use an application such as the one that propose. However there are enough software tools that work off schema to justify trying to define XML that can be easily defined in that language. Further, as you suggest yourself on the wiki, the refusal to provide normative schema for HL7v3 messages has been a source of frustration and confusion for implementers who expect to work from schema. We should deliver to these expectations (it is a lot easier than changing them). All the best Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 18 July 2006 16:27 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] Schemas for Validation?? > > hi > > I'm reading Ann's xml principles. I will comment on them. > but for now, a simple question. Why do we want schemas for > validation? Personally, I've always found them frustrating. > it seems that we want schemas cause that's all we have, yet > they are a poor mans tool... > > What, say, I wrote a java validation tool for the new ITS, > that worked off the MIF and XML source directly, and released > it under open source. > > pro's: > * MUCH better error messages > * much more thorough validation > * faster > * more usable > * one source of truth > > con's: > ? I can think of a few, but interested in comments and analysis > > If we had an open source java library/application like that, > would we still want schemas for validation? > > Grahame > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From ann.wrightson at bt.com Tue Jul 18 17:22:44 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 18 Jul 2006 17:22:44 +0100 Subject: [New-ITS] (Human) Readability of XML Message-ID: <849288029444F74899F8C8E3D479FF6DA1F882@E03MVZ3-UKDY.domain1.systemhost.net> The latter parts of the attached paper address ease vs difficulty of human-readability of XML. IMO a key scenario for readability (and HL7v3 adoptability) is where a developer is looking at a "type specimen" of some HL7v3 message and needing to understand what it means in order to devise appropriate processing of that kind of message into an existing clinical system (in particular, one without an internal model that conforms to the RIM). However much we'd prefer other approaches to predominate, unless this works easily we're stuffed (technically speaking ;-) Ann W. -------------- next part -------------- A non-text attachment was scrubbed... Name: EML2005Wrightson01.pdf Type: application/octet-stream Size: 88602 bytes Desc: EML2005Wrightson01.pdf Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060718/39a6c093/EML2005Wrightson01-0001.obj From grahame at kestral.com.au Tue Jul 18 17:47:09 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 02:47:09 +1000 Subject: [New-ITS] Schemas for Validation?? In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1F84F@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1F84F@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BD108D.9020804@kestral.com.au> Continuing to be a devil's advocate: > We want schemas - and IMO that means we also want XML that is friendly > to schema-validation but what does this mean? how far does this go? I guess that my real point here is that there's a tension between generally useful XML and XML that is real useful for schema validation. my feeling here is that you are advocating a middle road, Ann in a sense I am too - a do believe in delivering schema, but I don't believe in trying very hard to serve validation from the schemas - because they are a de facto industry standard for > checking that received XML meets minimum shape-and-content criteria for > admission into further processing. More middle of the road? > Reliance on schema-validation for > more than that is IMO not sensible in large volume data transfer. so I find myself interested in this too. Do users rely on schema in high volume data transfer production systems? is it denial-or-service protection? > Providing a java-based deeper validation sounds a useful extra, however > I'm sceptical of building anything onto MIF. yeah, well, that's detail. while everything is in MIF, it's a good place to build from. But when Hl7 moves away from it, then we won't be interested anymore > Providing only a java validation widget for an XML interoperability > format is (only) useful for people who are happy to incorporate > open-source java widgets into what they do (whatever you might think of > folks that don't, they do exist). I guess the idea here is that there are folks who want to do production checking. I understand about not wanting to include os java code in production systems. so we have a clear case for dual level validation - a sanity check in schema, and a full validation in some other technology? Grahame From grahame at kestral.com.au Tue Jul 18 17:48:14 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 02:48:14 +1000 Subject: [New-ITS] Schemas for Validation?? In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F504004BCD@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F504004BCD@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44BD10CE.1080600@kestral.com.au> hi Rik you know, this is the first time I've heard of someone doing anything with PSVI - I had completely overlooked it. is PSVI important? the UML ITS looks likely to render PSVI rather useless Grahame Smithies Rik wrote: > Hi, my thoughts, no particular order : > > There is a need/wish for CFH to distribute a machine readable spec that > suppliers can check their messages against. > > Traditionally only schema has been available as such a tool. > > Nowadays you could say that MIF fulfills the same role, but suppliers > aren't used to working with MIF, and it's still a moving target. > > A supplier may choose to ignore such a spec and write their own > validation, but not all will, so something everyone can understand is > wanted. > > If everyone was using such an open source validator, and CFH could > easily distribute rules for such a thing, then that would do it in > theory. But I think that some people like schemas, even if they don't > use them in all stages of development. > > Schemas have historically not been great validators, but CFH work is > improving on that, and there is still more that can be done. > > Schemas are about as widely adopted and understood as anything, even if > known to be imperfect. > > People are suspicious of new tools, more to learn, what if its is buggy, > not maintained, not on my platform, open source means I may have to look > at source, don't want lock in etc. > > Schemas can be used for PSVI working. I have done this in last few days > for my own purposes, running "simplified" messages into a viewing tool > that doesn't support them, by mangling the schemas to "de-simplify" the > messages on the fly. > > cheers, > Rik > >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve >> Sent: 18 July 2006 16:27 >> To: new-its at lists.hl7.org.uk >> Subject: [New-ITS] Schemas for Validation?? >> >> hi >> >> I'm reading Ann's xml principles. I will comment on them. >> but for now, a simple question. Why do we want schemas for >> validation? Personally, I've always found them frustrating. >> it seems that we want schemas cause that's all we have, yet >> they are a poor mans tool... >> >> What, say, I wrote a java validation tool for the new ITS, >> that worked off the MIF and XML source directly, and released >> it under open source. >> >> pro's: >> * MUCH better error messages >> * much more thorough validation >> * faster >> * more usable >> * one source of truth >> >> con's: >> ? I can think of a few, but interested in comments and analysis >> >> If we had an open source java library/application like that, >> would we still want schemas for validation? >> >> Grahame >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> > > This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Charlie at ramseysystems.co.uk Tue Jul 18 18:00:28 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Tue, 18 Jul 2006 18:00:28 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB5F@ramseysc1420.RamseyNet.local> Both This is the same discussion that raged in the XML SIG for too long -- there will be folk that want sanity checking schema, that work cleanly with WSDL, mapping tools, code generation etc - and there will be others that want validation schema that test quite long enumerations and detailed regex patterns etc - ie do as much validation as possible in the schema, without worrying about performance (ie use the schema during testing). The ITS could produce either or both, and could make either or both "normative". The current CFH schema-tightening work shows that there is an appetite for "as tight as possible" schema Until we know what the choices are, and what it is that we would have to do to get better validation, I suggest that we hold off judgement on this (while agreeing that a Java deep-validation tool would be useful anyway) All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 18 July 2006 17:47 > To: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Schemas for Validation?? > > Continuing to be a devil's advocate: > > > We want schemas - and IMO that means we also want XML that > is friendly > > to schema-validation > > but what does this mean? how far does this go? > > I guess that my real point here is that there's a tension > between generally useful XML and XML that is real useful for > schema validation. > my feeling here is that you are advocating a middle road, Ann > > in a sense I am too - a do believe in delivering schema, but > I don't believe in trying very hard to serve validation from > the schemas > > - because they are a de facto industry standard for > > checking that received XML meets minimum shape-and-content criteria > > for admission into further processing. > > More middle of the road? > > > Reliance on schema-validation for > > more than that is IMO not sensible in large volume data transfer. > > so I find myself interested in this too. Do users rely on > schema in high volume data transfer production systems? is it > denial-or-service protection? > > > Providing a java-based deeper validation sounds a useful extra, > > however I'm sceptical of building anything onto MIF. > > yeah, well, that's detail. while everything is in MIF, it's a > good place to build from. But when Hl7 moves away from it, > then we won't be interested anymore > > > Providing only a java validation widget for an XML interoperability > > format is (only) useful for people who are happy to incorporate > > open-source java widgets into what they do (whatever you > might think > > of folks that don't, they do exist). > > I guess the idea here is that there are folks who want to do > production checking. I understand about not wanting to > include os java code in production systems. > > so we have a clear case for dual level validation - a sanity > check in schema, and a full validation in some other technology? > > Grahame > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From ann.wrightson at bt.com Tue Jul 18 17:59:07 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 18 Jul 2006 17:59:07 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <849288029444F74899F8C8E3D479FF6DA1F8B9@E03MVZ3-UKDY.domain1.systemhost.net> I find the middle of the road (well, the middle of my side of the road) is usually a comfortable place to drive... ;-) Yes, the "dual level validation" approach is a pattern I've come to expect - with wide variety in what the second bit is. In fact it's often "dual" only from the viewpoint of the interop layer; a v. useful pattern that entitles that layer not to care about too much. Alternatively, you can switch viewpoints as the XML travels on, & you get a classic N-layer extension with respect to the 2-layer "dual" pattern. Ann W. -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: Tuesday, July 18, 2006 5:45 PM To: Wrightson,A,Ann,JPGA8Y C Cc: grahame at jivamedical.com Subject: Re: [New-ITS] Schemas for Validation?? Continuing to be a devil's advocate: > We want schemas - and IMO that means we also want XML that is friendly > to schema-validation but what does this mean? how far does this go? I guess that my real point here is that there's a tension between generally useful XML and XML that is real useful for schema validation. my feeling here is that you are advocating a middle road, Ann in a sense I am too - a do believe in delivering schema, but I don't believe in trying very hard to serve validation from the schemas - because they are a de facto industry standard for > checking that received XML meets minimum shape-and-content criteria > for admission into further processing. More middle of the road? > Reliance on schema-validation for > more than that is IMO not sensible in large volume data transfer. so I find myself interested in this too. Do users rely on schema in high volume data transfer production systems? is it denial-or-service protection? > Providing a java-based deeper validation sounds a useful extra, > however I'm sceptical of building anything onto MIF. yeah, well, that's detail. while everything is in MIF, it's a good place to build from. But when Hl7 moves away from it, then we won't be interested anymore > Providing only a java validation widget for an XML interoperability > format is (only) useful for people who are happy to incorporate > open-source java widgets into what they do (whatever you might think > of folks that don't, they do exist). I guess the idea here is that there are folks who want to do production checking. I understand about not wanting to include os java code in production systems. so we have a clear case for dual level validation - a sanity check in schema, and a full validation in some other technology? Grahame From rik.smithies at cfh.nhs.uk Tue Jul 18 18:05:08 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Tue, 18 Jul 2006 18:05:08 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <1A3D105C334EAE49BDDD93D8767573F504004C13@EXCHAQ2.nhsia.nhs.uk> Hi Grahame Until lately I see the PSVI as an oddity, or even a nuisance, because it means transforms on instances get spattered with "realmCode" etc all over the place, unless you move the schemas so the processor cant find them. But if we have schemas, as we do with GP Summary now, that make many structural attributes prohibited+fixed, you can convert the schemas so these are optional+default attributes. Then the PSVI of a simplified message is the inflated message that you want, with no further transform necessary. So by using simplification that sticks to removing attributes only (or mainly) you can have smaller instances that are still immediately processable and xpath'able. Which I think is pretty handy. But it only helps with less aggressive simplification strategies for when you want to quickly get back to the standard ITS. Or it means a simpler transform can add back missing elements, and you can leave missing attributes to the PSVI. If your new ITS is radically different then your older ITS processing code is going to have to change totally anyway, so losing this PSVI trick probably isn't a big deal (assuming you don't need to re-simplify your new ITS :-) I notice that PSVI support is mentioned as a goal of the original ITS, so someone must have thought it was useful. cheers, Rik > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 18 July 2006 17:48 > To: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Schemas for Validation?? > > hi Rik > > you know, this is the first time I've heard of someone doing > anything with PSVI - I had completely overlooked it. > > is PSVI important? the UML ITS looks likely to render PSVI > rather useless > > Grahame > > > Smithies Rik wrote: > > Hi, my thoughts, no particular order : > > > > There is a need/wish for CFH to distribute a machine readable spec > > that suppliers can check their messages against. > > > > Traditionally only schema has been available as such a tool. > > > > Nowadays you could say that MIF fulfills the same role, but > suppliers > > aren't used to working with MIF, and it's still a moving target. > > > > A supplier may choose to ignore such a spec and write their own > > validation, but not all will, so something everyone can > understand is > > wanted. > > > > If everyone was using such an open source validator, and CFH could > > easily distribute rules for such a thing, then that would do it in > > theory. But I think that some people like schemas, even if > they don't > > use them in all stages of development. > > > > Schemas have historically not been great validators, but > CFH work is > > improving on that, and there is still more that can be done. > > > > Schemas are about as widely adopted and understood as > anything, even > > if known to be imperfect. > > > > People are suspicious of new tools, more to learn, what if its is > > buggy, not maintained, not on my platform, open source means I may > > have to look at source, don't want lock in etc. > > > > Schemas can be used for PSVI working. I have done this in last few > > days for my own purposes, running "simplified" messages > into a viewing > > tool that doesn't support them, by mangling the schemas to > > "de-simplify" the messages on the fly. > > > > cheers, > > Rik > > > >> -----Original Message----- > >> From: new-its-bounces at lists.hl7.org.uk > >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of > Grahame Grieve > >> Sent: 18 July 2006 16:27 > >> To: new-its at lists.hl7.org.uk > >> Subject: [New-ITS] Schemas for Validation?? > >> > >> hi > >> > >> I'm reading Ann's xml principles. I will comment on them. > >> but for now, a simple question. Why do we want schemas for > >> validation? Personally, I've always found them frustrating. > >> it seems that we want schemas cause that's all we have, > yet they are > >> a poor mans tool... > >> > >> What, say, I wrote a java validation tool for the new ITS, that > >> worked off the MIF and XML source directly, and released it under > >> open source. > >> > >> pro's: > >> * MUCH better error messages > >> * much more thorough validation > >> * faster > >> * more usable > >> * one source of truth > >> > >> con's: > >> ? I can think of a few, but interested in comments and analysis > >> > >> If we had an open source java library/application like > that, would we > >> still want schemas for validation? > >> > >> Grahame > >> _______________________________________________ > >> New-ITS mailing list > >> New-ITS at lists.hl7.org.uk > >> http://lists.hl7.org.uk/mailman/listinfo/new-its > >> > > > > This e-mail is confidential and privileged. If you are not > the intended recipient please accept our apologies; please do > not disclose, copy or distribute information in this e-mail > or take any action in reliance on its contents: to do so is > strictly prohibited and may be unlawful. Please inform us > that this message has gone astray before deleting it. Thank > you for your co-operation. > > > > > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > From grahame at kestral.com.au Tue Jul 18 18:11:44 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 03:11:44 +1000 Subject: [New-ITS] Schemas for Validation?? In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FB5F@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FB5F@ramseysc1420.RamseyNet.local> Message-ID: <44BD1650.5070508@kestral.com.au> Well, you can't have it both ways with schema - the instances need to look different to serve the different outcomes. So you have to look to different techniques for different levels of validation. Grahame Charlie McCay wrote: > Both > > This is the same discussion that raged in the XML SIG for too long -- > there will be folk that want sanity checking schema, that work cleanly > with WSDL, mapping tools, code generation etc - and there will be others > that want validation schema that test quite long enumerations and > detailed regex patterns etc - ie do as much validation as possible in > the schema, without worrying about performance (ie use the schema during > testing). > > The ITS could produce either or both, and could make either or both > "normative". > > The current CFH schema-tightening work shows that there is an appetite > for "as tight as possible" schema > > Until we know what the choices are, and what it is that we would have to > do to get better validation, I suggest that we hold off judgement on > this (while agreeing that a Java deep-validation tool would be useful > anyway) > > All the best > > Charlie > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve >> Sent: 18 July 2006 17:47 >> To: new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Schemas for Validation?? >> >> Continuing to be a devil's advocate: >> >>> We want schemas - and IMO that means we also want XML that >> is friendly >>> to schema-validation >> but what does this mean? how far does this go? >> >> I guess that my real point here is that there's a tension >> between generally useful XML and XML that is real useful for >> schema validation. >> my feeling here is that you are advocating a middle road, Ann >> >> in a sense I am too - a do believe in delivering schema, but >> I don't believe in trying very hard to serve validation from >> the schemas >> >> - because they are a de facto industry standard for >>> checking that received XML meets minimum shape-and-content criteria >>> for admission into further processing. >> More middle of the road? >> >>> Reliance on schema-validation for >>> more than that is IMO not sensible in large volume data transfer. >> so I find myself interested in this too. Do users rely on >> schema in high volume data transfer production systems? is it >> denial-or-service protection? >> >>> Providing a java-based deeper validation sounds a useful extra, >>> however I'm sceptical of building anything onto MIF. >> yeah, well, that's detail. while everything is in MIF, it's a >> good place to build from. But when Hl7 moves away from it, >> then we won't be interested anymore >> >>> Providing only a java validation widget for an XML interoperability >>> format is (only) useful for people who are happy to incorporate >>> open-source java widgets into what they do (whatever you >> might think >>> of folks that don't, they do exist). >> I guess the idea here is that there are folks who want to do >> production checking. I understand about not wanting to >> include os java code in production systems. >> >> so we have a clear case for dual level validation - a sanity >> check in schema, and a full validation in some other technology? >> >> Grahame >> >> >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From ann.wrightson at bt.com Tue Jul 18 18:13:03 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 18 Jul 2006 18:13:03 +0100 Subject: [New-ITS] Schemas for Validation?? Message-ID: <849288029444F74899F8C8E3D479FF6DA1F8C8@E03MVZ3-UKDY.domain1.systemhost.net> I agree that old (& new) arguments should not "rage" in a sterile way - I also reckon the "some people will want" rhetoric is all wrong. The aim is fitness for one overriding purpose: widespread adoption by relative non-experts. To do that IMO we'll need to achieve something that's a fair bit simpler and stupider than any of us would really like. Ann W. -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Charlie McCay Sent: Tuesday, July 18, 2006 6:00 PM To: grahame at jivamedical.com; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Schemas for Validation?? Both This is the same discussion that raged in the XML SIG for too long -- there will be folk that want sanity checking schema, that work cleanly with WSDL, mapping tools, code generation etc - and there will be others that want validation schema that test quite long enumerations and detailed regex patterns etc - ie do as much validation as possible in the schema, without worrying about performance (ie use the schema during testing). The ITS could produce either or both, and could make either or both "normative". The current CFH schema-tightening work shows that there is an appetite for "as tight as possible" schema Until we know what the choices are, and what it is that we would have to do to get better validation, I suggest that we hold off judgement on this (while agreeing that a Java deep-validation tool would be useful anyway) All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 18 July 2006 17:47 > To: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Schemas for Validation?? > > Continuing to be a devil's advocate: > > > We want schemas - and IMO that means we also want XML that > is friendly > > to schema-validation > > but what does this mean? how far does this go? > > I guess that my real point here is that there's a tension between > generally useful XML and XML that is real useful for schema > validation. > my feeling here is that you are advocating a middle road, Ann > > in a sense I am too - a do believe in delivering schema, but I don't > believe in trying very hard to serve validation from the schemas > > - because they are a de facto industry standard for > > checking that received XML meets minimum shape-and-content criteria > > for admission into further processing. > > More middle of the road? > > > Reliance on schema-validation for > > more than that is IMO not sensible in large volume data transfer. > > so I find myself interested in this too. Do users rely on schema in > high volume data transfer production systems? is it denial-or-service > protection? > > > Providing a java-based deeper validation sounds a useful extra, > > however I'm sceptical of building anything onto MIF. > > yeah, well, that's detail. while everything is in MIF, it's a good > place to build from. But when Hl7 moves away from it, then we won't be > interested anymore > > > Providing only a java validation widget for an XML interoperability > > format is (only) useful for people who are happy to incorporate > > open-source java widgets into what they do (whatever you > might think > > of folks that don't, they do exist). > > I guess the idea here is that there are folks who want to do > production checking. I understand about not wanting to include os java > code in production systems. > > so we have a clear case for dual level validation - a sanity check in > schema, and a full validation in some other technology? > > Grahame > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From ann.wrightson at bt.com Tue Jul 18 18:15:18 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Tue, 18 Jul 2006 18:15:18 +0100 Subject: [New-ITS] Simplicity of XML Message-ID: <849288029444F74899F8C8E3D479FF6DA1F8C9@E03MVZ3-UKDY.domain1.systemhost.net> Some more food for thought: A series of thought-pieces (of varying weight) from Rick Jelliffe: http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_1_el e.html http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_2_pr o.html http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_3_xm l_1.html http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_4_xm l_1.html http://www.oreillynet.com/xml/blog/2006/05/metrics_for_xml_projects_5_st r_1.html And a simple description of cyclomatic complexity, that despite its offputting name could be adapted to give a nice metric for the degree of optionality expressed in a schema: http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html Ann W. From Galen.Mulrooney at va.gov Tue Jul 18 18:44:57 2006 From: Galen.Mulrooney at va.gov (Mulrooney, Galen (Patriot Tech)) Date: Tue, 18 Jul 2006 13:44:57 -0400 Subject: [New-ITS] Schemas for Validation?? Message-ID: <42DCCEE7B3AE4B4EB5E00FE8BF38D1FD0AA18E6B@VHAISWMSG1.vha.med.va.gov> FWIW, in the VHA, we plan to validate XML instances using a DOM and XSD; then, after a reasonable number of those messages have passed without incident (say after 50,000 messages, or perhaps 2 weeks of processing), switch to SAX. This allows us to have the safety of 100% schema validation during a testing period, while sacrificing speed; then turning up the speed and dealing with any failures manually in a "dead-letter" queue. Should the message definition change in the future, or a new application has come on line, we simply switch back to the full-validation mode using the XSD. Kind Regards, -=Galen=- Galen Mulrooney Lead Modeler, VHA Health Information Model (VHIM) Veteran's Health Administration (VHA) Office of Information, Health Information Architecture Galen.Mulrooney at va.gov +1.703.742.2866 -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve Sent: Tuesday, July 18, 2006 1:12 PM To: Charlie McCay Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Schemas for Validation?? Well, you can't have it both ways with schema - the instances need to look different to serve the different outcomes. So you have to look to different techniques for different levels of validation. Grahame Charlie McCay wrote: > Both > > This is the same discussion that raged in the XML SIG for too long -- > there will be folk that want sanity checking schema, that work cleanly > with WSDL, mapping tools, code generation etc - and there will be others > that want validation schema that test quite long enumerations and > detailed regex patterns etc - ie do as much validation as possible in > the schema, without worrying about performance (ie use the schema during > testing). > > The ITS could produce either or both, and could make either or both > "normative". > > The current CFH schema-tightening work shows that there is an appetite > for "as tight as possible" schema > > Until we know what the choices are, and what it is that we would have to > do to get better validation, I suggest that we hold off judgement on > this (while agreeing that a Java deep-validation tool would be useful > anyway) > > All the best > > Charlie > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve >> Sent: 18 July 2006 17:47 >> To: new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Schemas for Validation?? >> >> Continuing to be a devil's advocate: >> >>> We want schemas - and IMO that means we also want XML that >> is friendly >>> to schema-validation >> but what does this mean? how far does this go? >> >> I guess that my real point here is that there's a tension >> between generally useful XML and XML that is real useful for >> schema validation. >> my feeling here is that you are advocating a middle road, Ann >> >> in a sense I am too - a do believe in delivering schema, but >> I don't believe in trying very hard to serve validation from >> the schemas >> >> - because they are a de facto industry standard for >>> checking that received XML meets minimum shape-and-content criteria >>> for admission into further processing. >> More middle of the road? >> >>> Reliance on schema-validation for >>> more than that is IMO not sensible in large volume data transfer. >> so I find myself interested in this too. Do users rely on >> schema in high volume data transfer production systems? is it >> denial-or-service protection? >> >>> Providing a java-based deeper validation sounds a useful extra, >>> however I'm sceptical of building anything onto MIF. >> yeah, well, that's detail. while everything is in MIF, it's a >> good place to build from. But when Hl7 moves away from it, >> then we won't be interested anymore >> >>> Providing only a java validation widget for an XML interoperability >>> format is (only) useful for people who are happy to incorporate >>> open-source java widgets into what they do (whatever you >> might think >>> of folks that don't, they do exist). >> I guess the idea here is that there are folks who want to do >> production checking. I understand about not wanting to >> include os java code in production systems. >> >> so we have a clear case for dual level validation - a sanity >> check in schema, and a full validation in some other technology? >> >> Grahame >> >> >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From grahame at kestral.com.au Wed Jul 19 04:14:38 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 13:14:38 +1000 Subject: [New-ITS] extensibility Message-ID: <44BDA39E.2030208@kestral.com.au> hi Ann I am working my way through the many documents you have referred to. One subject that's come up a few times is extensibility. People want it, HL7 may or may not provide it. What does it mean? Grahame From grahame at kestral.com.au Wed Jul 19 04:26:25 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 13:26:25 +1000 Subject: [New-ITS] Schema question Message-ID: <44BDA661.2050803@kestral.com.au> hi There's 2 different ways to do an element declaration: ... or ... I've got a strong preference for the second, but I'm reading the UBL NDR, and they are saying the first serves reusability better. I find that odd, the second expresses exactly the amount of reusability I'm used to having (in a 3GL). What have I missed? Any other pro's and con's? Grahame From grahame at kestral.com.au Wed Jul 19 07:08:15 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 16:08:15 +1000 Subject: [New-ITS] Simplicity of XML In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1F8C9@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1F8C9@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BDCC4F.4080609@kestral.com.au> > And a simple description of cyclomatic complexity, that despite its > offputting name could be adapted to give a nice metric for the degree of > optionality expressed in a schema: > > http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html this is interesting. First a comment about cyclomatic complexity and code. One of the leading programmers I have worked with was a master at reducing cyclomatic complexity. It was unusual to see him do anything over 4. All fine, but he produced a litany of classes with a litany of methods on each. It gets harder and harder to work with this; complexity exists and if you push it down in one guise, it will reappear in another. how might one adapt this to schema? I don't see anything analogous. count the number of optional attributes and elements? What will this give us? Grahame From grahame at kestral.com.au Wed Jul 19 07:49:43 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 16:49:43 +1000 Subject: [New-ITS] UML attributes vs associations Message-ID: <44BDD607.7030200@kestral.com.au> Would anyone like to express an opinion on the subject of using attributes or associations in the UML for the implementable model? Grahame From tim.benson at abies.co.uk Wed Jul 19 08:23:11 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 19 Jul 2006 08:23:11 +0100 Subject: [New-ITS] UML attributes vs associations In-Reply-To: <44BDD607.7030200@kestral.com.au> Message-ID: UML allows you to anything you like, but in general modelling I like to see associations to separate classes when multiplicities are 0..* or 1..* (SET, LIST or BAG); Attributes are best when their multiplicities are either 1..1 or 0..1. This is reinforced when the relevant objects have a complex structure (e.g. Name, address and telecom) and the objects represent discrete real world things which would usually be handled as separate classes in a host system. Things that are closely related work well as attributes of the same class, even if they are at opposite ends of the RIM e.g. Date of Death (Entity) and Death Notification Status (Act). Tim On 19/7/06 07:49 Grahame Grieve wrote: > Would anyone like to express an opinion on the > subject of using attributes or associations in > the UML for the implementable model? > > Grahame > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > From grahame at kestral.com.au Wed Jul 19 08:51:00 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 17:51:00 +1000 Subject: [New-ITS] UML attributes vs associations In-Reply-To: References: Message-ID: <44BDE464.5040003@kestral.com.au> hi Tim thanks. I think it makes sense, but what, specifically, makes things better one way or another? is it just style? I guess in the context of an implementable model, we have a tree not an acyclic graph, so aggregation is firmly resolved and attributes vs associations seems to have less impact that it otherwise might? Grahame Tim Benson wrote: > UML allows you to anything you like, but in general modelling I like to see > associations to separate classes when multiplicities are 0..* or 1..* (SET, > LIST or BAG); Attributes are best when their multiplicities are either 1..1 > or 0..1. > > This is reinforced when the relevant objects have a complex structure (e.g. > Name, address and telecom) and the objects represent discrete real world > things which would usually be handled as separate classes in a host system. > > Things that are closely related work well as attributes of the same class, > even if they are at opposite ends of the RIM e.g. Date of Death (Entity) > and Death Notification Status (Act). > > > Tim > > > > On 19/7/06 07:49 Grahame Grieve wrote: > >> Would anyone like to express an opinion on the >> subject of using attributes or associations in >> the UML for the implementable model? >> >> Grahame >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From ian.townend at cfh.nhs.uk Wed Jul 19 08:59:16 2006 From: ian.townend at cfh.nhs.uk (Townend Ian) Date: Wed, 19 Jul 2006 08:59:16 +0100 Subject: [New-ITS] Schema question Message-ID: <3320F9E4BE367C4281A5A836B7627756014CBABB@EXCH1LDS.nhsia.nhs.uk> I can't see that it would strictly make it more re-usable since you could access element b in either. With both examples, you can access the element by declaring an element with type=A and it will become a sub-element of whatever element is of type A. The first example will also allow for the element to be ref'd directly so it can just be included on it's own rather than creating a complex type within a complex type. e.g. first example (with complexType A removed since it's not needed here): Second example: Ian Ian Townend Senior HL7 Practitioner Communications and Messaging NHS Connecting for Health 2nd Floor Princes Exchange, Princes Square, Leeds, LS1 4HY Telephone: 0113 280 6743 Mobile: 07717480383 ian.townend at cfh.nhs.uk www.connectingforhealth.nhs.uk -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve Sent: 19 July 2006 04:26 To: new-its at lists.hl7.org.uk Subject: [New-ITS] Schema question hi There's 2 different ways to do an element declaration: ... or ... I've got a strong preference for the second, but I'm reading the UBL NDR, and they are saying the first serves reusability better. I find that odd, the second expresses exactly the amount of reusability I'm used to having (in a 3GL). What have I missed? Any other pro's and con's? Grahame _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. From ann.wrightson at bt.com Wed Jul 19 10:16:24 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 10:16:24 +0100 Subject: [New-ITS] Element content vs attributes Message-ID: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> Here is a reference on this rather fundamental matter: http://xml.coverpages.org/elementsAndAttrs.html Ann W. From ann.wrightson at bt.com Wed Jul 19 11:11:27 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 11:11:27 +0100 Subject: [New-ITS] Simplicity of XML Message-ID: <849288029444F74899F8C8E3D479FF6DA1FC60@E03MVZ3-UKDY.domain1.systemhost.net> Grahame, I'm looking for a suitable surrogate measure for the rather vague concept of how diverse (in ways that matter) is the class of instances that schema-validates against a given schema, that itself is a surrogate for the usability property of "how predictable is this kind of stuff to process". Stepping back a little, I'm looking for ways to characterize more exactly the kind of simplicity that we're trying to achieve; I'm certain there are multiple dimensions and that there will be multiple trade-offs between them. I'm also looking (unsuccessfully so far) for useful background on mediating between close-to-business & analytically-abstract modelling (i.e. mediating explicitly rather than talking about whether to do one or the other, deciding, then building models & stuff). Cheers Ann W. -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: Wednesday, July 19, 2006 7:08 AM To: Wrightson,A,Ann,JPGA8Y C Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Simplicity of XML > And a simple description of cyclomatic complexity, that despite its > offputting name could be adapted to give a nice metric for the degree > of optionality expressed in a schema: > > http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html this is interesting. First a comment about cyclomatic complexity and code. One of the leading programmers I have worked with was a master at reducing cyclomatic complexity. It was unusual to see him do anything over 4. All fine, but he produced a litany of classes with a litany of methods on each. It gets harder and harder to work with this; complexity exists and if you push it down in one guise, it will reappear in another. how might one adapt this to schema? I don't see anything analogous. count the number of optional attributes and elements? What will this give us? Grahame From tim.benson at abies.co.uk Wed Jul 19 11:48:52 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 19 Jul 2006 11:48:52 +0100 Subject: [New-ITS] UML attributes vs associations In-Reply-To: <44BDE464.5040003@kestral.com.au> Message-ID: Graham, When using UML we are primarily concerned with precise human to human communication, so the method which gives less chance of misunderstanding and error by different readers of the model or diagram is preferred. Attribute multiplicities greater than 1, complex attribute types and splitting closely-related things into different classes are three independent issues, covered in my original reply. All three lead to frequent misunderstandings on first reading, as indicated by the amount of time devoted to explaining them in committee meetings. On the issue of trees and acyclic graphs, both message analysis models and implementable models should be trees. This reminds me of two other easily preventable causes of misunderstanding, namely failure to make association navigation and multiplicities explicit. Therefore, all associations should include navigation arrows showing that they can only be read in the direction specified . Finally, all association and attribute multiplicities should be shown, even when they are [1] (the standard default). Tim On 19/7/06 08:51 Grahame Grieve wrote: > hi Tim > > thanks. I think it makes sense, but what, specifically, makes > things better one way or another? > > is it just style? > > I guess in the context of an implementable model, we have a tree > not an acyclic graph, so aggregation is firmly resolved and > attributes vs associations seems to have less impact that it > otherwise might? > > Grahame > > > Tim Benson wrote: >> UML allows you to anything you like, but in general modelling I like to see >> associations to separate classes when multiplicities are 0..* or 1..* (SET, >> LIST or BAG); Attributes are best when their multiplicities are either 1..1 >> or 0..1. >> >> This is reinforced when the relevant objects have a complex structure (e.g. >> Name, address and telecom) and the objects represent discrete real world >> things which would usually be handled as separate classes in a host system. >> >> Things that are closely related work well as attributes of the same class, >> even if they are at opposite ends of the RIM e.g. Date of Death (Entity) >> and Death Notification Status (Act). >> >> >> Tim >> >> >> >> On 19/7/06 07:49 Grahame Grieve wrote: >> >>> Would anyone like to express an opinion on the >>> subject of using attributes or associations in >>> the UML for the implementable model? >>> >>> Grahame >>> _______________________________________________ >>> New-ITS mailing list >>> New-ITS at lists.hl7.org.uk >>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>> >> >> >> From ann.wrightson at bt.com Wed Jul 19 11:51:51 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 11:51:51 +0100 Subject: [New-ITS] extensibility Message-ID: <849288029444F74899F8C8E3D479FF6DA1FD0C@E03MVZ3-UKDY.domain1.systemhost.net> Grahame, It means different things to different people, as ever. Business/political level: At worst a demand for extensibility means "we must be able to sign up to this standard without changing any of what we already do..."; not much better is when it's just a way to get signoff across a group who each want their own options in (& forget that interoperation means they'll have to accept & process everyone else's options). A formulation that I find works well to get the point across when I'm presenting this kind of stuff is "My extensions & variations help me; everyone else's extensions & variations hinder me; since I am a minority, what probably helps me most is to have no extensions or variations at all" ...unless of course I only interoperate with people I control...which is probably what many adopters actually want to do :) Technical level: There appears to be a quasi-religious difference between those who prefer their extensibility inheritance-style, as the ability to refine and add into what is given, and those who prefer their extensibility component-style, where unchangeable components of useful size (not too large, not too small) can be selected and rearranged as required, and new components created for new needs. I believe the former is more congenial for modelling, and the latter more practical for version-managing and configuration-managing an ongoing corpus of stuff of whatever kind. There's also the characteristic of being modular and separating concerns, informally: - I can adopt just the stuff I need without too much brainache, special setup or performance overhead - if I need more later, it's an easy upgrade (and doesn't break the old stuff I need to keep) - my standard doesn't mess up your standard when they're used together Ann W. -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve Sent: Wednesday, July 19, 2006 4:15 AM To: new-its at lists.hl7.org.uk Subject: [New-ITS] extensibility hi Ann I am working my way through the many documents you have referred to. One subject that's come up a few times is extensibility. People want it, HL7 may or may not provide it. What does it mean? Grahame _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its From ann.wrightson at bt.com Wed Jul 19 11:59:58 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 11:59:58 +0100 Subject: [New-ITS] UML attributes vs associations Message-ID: <849288029444F74899F8C8E3D479FF6DA1FD2E@E03MVZ3-UKDY.domain1.systemhost.net> Tim said: When using UML we are primarily concerned with precise human to human communication, so the method which gives less chance of misunderstanding and error by different readers of the model or diagram is preferred. I say: We shouldn't forget that a principal purpose of the UML models we're dealing with here is to generate easy-to-use XML messaging - as well as communicate to humans. Ann W. From tim.benson at abies.co.uk Wed Jul 19 12:52:06 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 19 Jul 2006 12:52:06 +0100 Subject: [New-ITS] UML attributes vs associations In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FD2E@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: Ann, This is a very important point. There are two distinct sets of requirements: (1) Models used to represent the data that goes over the wire (ITS). These have to be understood precisely by the integration engineers, and the software developers at all nodes. These should be closely related to the XML messages. You should not expect domain experts to understand these in detail (no more than you should expect accountants to understand COBOL source code). (2) Models which need to be understood by domain experts. Domain experts need to be able to review, check, comment on and analyse the potential consequences of adopting a set of messages. They need models that they can understand, and such specifications need to just as stringent as those of (1) above, but some technical details can be left out. These models also need to be shared with and understood by integration engineers and software developers. Ideally one should be able to round-trip between the two types of model via XMI. Both types of model need to support precise human to human communication: Type (1) between integration engineers and software developers; Type (2) between domain experts, software developers and integration engineers. There is little or no evidence to support the idea that we know how to develop models that can do both jobs using the same model, and plenty of bitter experience that most previous attempts have not been successful. Tim On 19/7/06 11:59 ann.wrightson at bt.com wrote: > Tim said: > > When using UML we are primarily concerned with precise human to human > communication, so the method which gives less chance of misunderstanding > and error by different readers of the model or diagram is preferred. > > I say: > > We shouldn't forget that a principal purpose of the UML models we're > dealing with here is to generate easy-to-use XML messaging - as well as > communicate to humans. > > Ann W. > From grahame at kestral.com.au Wed Jul 19 13:17:08 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 22:17:08 +1000 Subject: [New-ITS] UML attributes vs associations In-Reply-To: References: Message-ID: <44BE22C4.4010902@kestral.com.au> so does the subsequent exchange about the primary concern of the UML diagrams change any your views expressed here? Grahame Tim Benson wrote: > Graham, > > When using UML we are primarily concerned with precise human to human > communication, so the method which gives less chance of misunderstanding and > error by different readers of the model or diagram is preferred. > > Attribute multiplicities greater than 1, complex attribute types and > splitting closely-related things into different classes are three > independent issues, covered in my original reply. All three lead to > frequent misunderstandings on first reading, as indicated by the amount of > time devoted to explaining them in committee meetings. > > On the issue of trees and acyclic graphs, both message analysis models and > implementable models should be trees. > > This reminds me of two other easily preventable causes of misunderstanding, > namely failure to make association navigation and multiplicities explicit. > > Therefore, all associations should include navigation arrows showing that > they can only be read in the direction specified . > > Finally, all association and attribute multiplicities should be shown, even > when they are [1] (the standard default). > > Tim > > > On 19/7/06 08:51 Grahame Grieve wrote: > >> hi Tim >> >> thanks. I think it makes sense, but what, specifically, makes >> things better one way or another? >> >> is it just style? >> >> I guess in the context of an implementable model, we have a tree >> not an acyclic graph, so aggregation is firmly resolved and >> attributes vs associations seems to have less impact that it >> otherwise might? >> >> Grahame >> >> >> Tim Benson wrote: >>> UML allows you to anything you like, but in general modelling I like to see >>> associations to separate classes when multiplicities are 0..* or 1..* (SET, >>> LIST or BAG); Attributes are best when their multiplicities are either 1..1 >>> or 0..1. >>> >>> This is reinforced when the relevant objects have a complex structure (e.g. >>> Name, address and telecom) and the objects represent discrete real world >>> things which would usually be handled as separate classes in a host system. >>> >>> Things that are closely related work well as attributes of the same class, >>> even if they are at opposite ends of the RIM e.g. Date of Death (Entity) >>> and Death Notification Status (Act). >>> >>> >>> Tim >>> >>> >>> >>> On 19/7/06 07:49 Grahame Grieve wrote: >>> >>>> Would anyone like to express an opinion on the >>>> subject of using attributes or associations in >>>> the UML for the implementable model? >>>> >>>> Grahame >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >>> >>> > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Wed Jul 19 13:21:52 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 22:21:52 +1000 Subject: [New-ITS] Element content vs attributes In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BE23E0.2010409@kestral.com.au> > http://xml.coverpages.org/elementsAndAttrs.html so, from that link, I found this: Procedure for UML to Syntax Schema conversion Given an arbitrary UML diagram, we can mechanically produce a canonical grammar. 1. Objects are expressed as elements. They always have id attributes. 2. Properties are expressed as attributes. 3. Relations are expressed as attributes. The value of the attribute is an idref (or space-separated list of idrefs) to the related element. (Relations to objects not in the serialized instance have datatype uri or uris.) 4. The top-level element is the name of the package or message. 5. The top-level element has a content model which allows any other element type in any order. 6. If an object can only be referenced once, and its existence is dependent on the existence of another element, it may also appear in the content model of the referencing element (which continues to have an attribute making the relation explicit). 7. Regarding ordering, content models use a group that allows sub-elements to appear in any order. 8. A relation between elements could be expressed as an attribute of either side. To choose which side gets the content, 1. If only one role is named, use that, else 2. Pick the role with the smallest maximum cardinality, else 3. Pick the role with the largest minimum cardinality, else 4. Pick the role with the shortest name, else 5. Pick the role whose name appears first in the alphabet. This is a rather different view of how you should represent instances of a UML class diagram in XML comments? Grahame ann.wrightson at bt.com wrote: > Here is a reference on this rather fundamental matter: > > Ann W. > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Wed Jul 19 13:22:33 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 22:22:33 +1000 Subject: [New-ITS] Element content vs attributes In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BE2409.9090001@kestral.com.au> I am left with a simple view: attributes are better cause they use less space, so use them when you can. Grahame ann.wrightson at bt.com wrote: > Here is a reference on this rather fundamental matter: > http://xml.coverpages.org/elementsAndAttrs.html > > Ann W. > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Charlie at ramseysystems.co.uk Wed Jul 19 13:32:58 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Wed, 19 Jul 2006 13:32:58 +0100 Subject: [New-ITS] Schema question Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB64@ramseysc1420.RamseyNet.local> Grahame The diversity is increased when you consider using anonymous types as well (in both approaches you could include the definition of the type B in the definition of the element "b" so that there is no type named B). In the second case this would result in duplicate definitions, but that is not the case for global elements approach. It is easier to work with element and attribute names in XML technology than it is to work with type names. In XSLT and xPath release 1 you don't have easy access to the types, and in release 2 it is better but still not as easy as using the element/attribute names. This is also closely related to how xsi:type may/should/must be used. Where there is a global type defined for an XML element, then it will always be schema-valid to include an xsi:type assertion that that is the type being used. Where there is a choice of possible types, then it is required that xsi:type be included. In the current instances there are only a few places where xsi:type is needed, and maybe we should look at those, and see if the variability is justified. Setting all the types in the schema would certainly be a form of simplification - but may be too expensive in practice. Whether it is useful to have named types in the schema depends on how you are using the schema -- it makes no difference for validation, but the type names are used by object builders so if that is what you want the schema for then you will like named types. Globally declared elements make finding the root element in a schema browser a bit tricky, and allows documents that have a different element as the root node seem to be schema-valid. However in a world of hand-crafted schema (not one that we are addressing) the benefit of globally defined elements is that element names that should be consistent are validated as such (if there is a typo in the name then the ref will be broken). In summary component based reuse using element/attribute names should be the primary focus for implementation reuse, with type names being used to support that. Whether types should be fully determined by the definition of the message is to be established. All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 19 July 2006 04:26 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] Schema question > > hi > > There's 2 different ways to do an element declaration: > > > > > > > > > ... > > > or > > > > > > > ... > > > I've got a strong preference for the second, but I'm reading > the UBL NDR, and they are saying the first serves reusability > better. I find that odd, the second expresses exactly the > amount of reusability I'm used to having (in a 3GL). What > have I missed? > > Any other pro's and con's? > > Grahame > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From tim.benson at abies.co.uk Wed Jul 19 13:48:09 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 19 Jul 2006 13:48:09 +0100 Subject: [New-ITS] UML attributes vs associations In-Reply-To: <44BE22C4.4010902@kestral.com.au> Message-ID: Grahame No. Not in any way that I can think of. Whether the primary audience is domain experts or software engineers we are still have a paramount concern to minimise the possibility of ambiguity, misunderstandings and hence errors. Tim On 19/7/06 13:17 Grahame Grieve wrote: > so does the subsequent exchange about the primary concern of > the UML diagrams change any your views expressed here? > > Grahame > > > Tim Benson wrote: >> Graham, >> >> When using UML we are primarily concerned with precise human to human >> communication, so the method which gives less chance of misunderstanding and >> error by different readers of the model or diagram is preferred. >> >> Attribute multiplicities greater than 1, complex attribute types and >> splitting closely-related things into different classes are three >> independent issues, covered in my original reply. All three lead to >> frequent misunderstandings on first reading, as indicated by the amount of >> time devoted to explaining them in committee meetings. >> >> On the issue of trees and acyclic graphs, both message analysis models and >> implementable models should be trees. >> >> This reminds me of two other easily preventable causes of misunderstanding, >> namely failure to make association navigation and multiplicities explicit. >> >> Therefore, all associations should include navigation arrows showing that >> they can only be read in the direction specified . >> >> Finally, all association and attribute multiplicities should be shown, even >> when they are [1] (the standard default). >> >> Tim >> >> >> On 19/7/06 08:51 Grahame Grieve wrote: >> >>> hi Tim >>> >>> thanks. I think it makes sense, but what, specifically, makes >>> things better one way or another? >>> >>> is it just style? >>> >>> I guess in the context of an implementable model, we have a tree >>> not an acyclic graph, so aggregation is firmly resolved and >>> attributes vs associations seems to have less impact that it >>> otherwise might? >>> >>> Grahame >>> >>> >>> Tim Benson wrote: >>>> UML allows you to anything you like, but in general modelling I like to see >>>> associations to separate classes when multiplicities are 0..* or 1..* (SET, >>>> LIST or BAG); Attributes are best when their multiplicities are either 1..1 >>>> or 0..1. >>>> >>>> This is reinforced when the relevant objects have a complex structure (e.g. >>>> Name, address and telecom) and the objects represent discrete real world >>>> things which would usually be handled as separate classes in a host system. >>>> >>>> Things that are closely related work well as attributes of the same class, >>>> even if they are at opposite ends of the RIM e.g. Date of Death (Entity) >>>> and Death Notification Status (Act). >>>> >>>> >>>> Tim >>>> >>>> >>>> >>>> On 19/7/06 07:49 Grahame Grieve wrote: >>>> >>>>> Would anyone like to express an opinion on the >>>>> subject of using attributes or associations in >>>>> the UML for the implementable model? >>>>> >>>>> Grahame >>>>> _______________________________________________ >>>>> New-ITS mailing list >>>>> New-ITS at lists.hl7.org.uk >>>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>>> >>>> >>>> >> >> >> From ann.wrightson at bt.com Wed Jul 19 13:53:48 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 13:53:48 +0100 Subject: [New-ITS] Element content vs attributes Message-ID: <849288029444F74899F8C8E3D479FF6DA83C45@E03MVZ3-UKDY.domain1.systemhost.net> >This is a rather different view of how you should represent instances of a UML class diagram in XML Yes it is - & see also http://www.xml.com/pub/a/2002/08/07/wxs_uml.html for a simple one that goes the other way... Neither of these are particularly useful IMO for what we need to do, however these patterns of thought are part of the space in which we're working. Ann W. -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: Wednesday, July 19, 2006 1:22 PM To: Wrightson,A,Ann,JPGA8Y C Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Element content vs attributes > http://xml.coverpages.org/elementsAndAttrs.html so, from that link, I found this: Procedure for UML to Syntax Schema conversion Given an arbitrary UML diagram, we can mechanically produce a canonical grammar. 1. Objects are expressed as elements. They always have id attributes. 2. Properties are expressed as attributes. 3. Relations are expressed as attributes. The value of the attribute is an idref (or space-separated list of idrefs) to the related element. (Relations to objects not in the serialized instance have datatype uri or uris.) 4. The top-level element is the name of the package or message. 5. The top-level element has a content model which allows any other element type in any order. 6. If an object can only be referenced once, and its existence is dependent on the existence of another element, it may also appear in the content model of the referencing element (which continues to have an attribute making the relation explicit). 7. Regarding ordering, content models use a group that allows sub-elements to appear in any order. 8. A relation between elements could be expressed as an attribute of either side. To choose which side gets the content, 1. If only one role is named, use that, else 2. Pick the role with the smallest maximum cardinality, else 3. Pick the role with the largest minimum cardinality, else 4. Pick the role with the shortest name, else 5. Pick the role whose name appears first in the alphabet. This is a rather different view of how you should represent instances of a UML class diagram in XML comments? Grahame ann.wrightson at bt.com wrote: > Here is a reference on this rather fundamental matter: > > Ann W. > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Wed Jul 19 13:58:17 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 22:58:17 +1000 Subject: [New-ITS] Element content vs attributes In-Reply-To: <849288029444F74899F8C8E3D479FF6DA83C45@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA83C45@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BE2C69.8060102@kestral.com.au> > Neither of these are particularly useful IMO for what we need to do, > however these patterns of thought are part of the space in which we're > working. good - but why are they not useful? - I am just trying to stimulate discussion in this space. Grahame From ann.wrightson at bt.com Wed Jul 19 14:06:02 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 14:06:02 +0100 Subject: [New-ITS] Element content vs attributes Message-ID: <849288029444F74899F8C8E3D479FF6DA83C7C@E03MVZ3-UKDY.domain1.systemhost.net> My own opinion: Conveying meaning by arranging content *in* a suitable structure of well-named elements is at the heart of XML, and using XML in a way that doesn't work like that is ugly misuse. Attributes are, from this perspective, metadata on elements, saying something about the element (or what needs to be done with it, etc) rather than constituting the element. Message size is a matter of optimization,and like all optimizations should be thought about after lots of other stuff is right, not at the start. Ann W. From grahame at kestral.com.au Wed Jul 19 14:08:40 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 23:08:40 +1000 Subject: [New-ITS] Schema question In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FB64@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FB64@ramseysc1420.RamseyNet.local> Message-ID: <44BE2ED8.3040609@kestral.com.au> > The diversity is increased when you consider using anonymous types as > well (in both approaches you could include the definition of the type B > in the definition of the element "b" so that there is no type named B). I couldn't bring myself to mention anonymous types. shame on you for thinking of it. > In the second case this would result in duplicate definitions, but that > is not the case for global elements approach. > > It is easier to work with element and attribute names in XML technology > than it is to work with type names. In XSLT and xPath release 1 you > don't have easy access to the types, and in release 2 it is better but > still not as easy as using the element/attribute names. interesting point. good point. But I draw the complete opposite conclusion from what you say as a conclusion to this: > In summary component based reuse using element/attribute names should be > the primary focus for implementation reuse the reason is simple. If you use element names by reference, then you are saying that every use of the element name x must have the same type. In the context where the abstract model uses clones of the same (meta)class and imposes different constraints, which become types(?), then you start having to mangle names in the schemas to do element references. so you actually make more of a mess of the names. So the current method (venetian blind) becomes the only way to go. We could only go with element names as I discuss below if the abstract modeling guaranteed that any (UML) attribute with the same name had the same type and constraint information. And I think that would be a bad thing. As for polymorphism, you have a more compelling argument. But I think the relevant principle here is "keep it as simple as you can, but not more simple" - trying to flatten the polymorphism would be too much simplification - unless we can remove it from the model. The primary places where we will have polymorphism in the IM's is the stitching points and where ANY is used in the RIM. Grahame From grahame at kestral.com.au Wed Jul 19 14:11:05 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 23:11:05 +1000 Subject: [New-ITS] Simplicity of XML In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FC60@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1FC60@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BE2F69.2080902@kestral.com.au> interesting. how about the (square or optional elements + attributes) / #types (where #types includes named and anonymous and element and group refs are dereferenced, and optional refers to 0..1, not 0..*, or 1..1 with nillable flag) Grahame ann.wrightson at bt.com wrote: > Grahame, > > I'm looking for a suitable surrogate measure for the rather vague > concept of how diverse (in ways that matter) is the class of instances > that schema-validates against a given schema, that itself is a surrogate > for the usability property of "how predictable is this kind of stuff to > process". Stepping back a little, I'm looking for ways to characterize > more exactly the kind of simplicity that we're trying to achieve; I'm > certain there are multiple dimensions and that there will be multiple > trade-offs between them. > > I'm also looking (unsuccessfully so far) for useful background on > mediating between close-to-business & analytically-abstract modelling > (i.e. mediating explicitly rather than talking about whether to do one > or the other, deciding, then building models & stuff). > > Cheers > > Ann W. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame > Grieve > Sent: Wednesday, July 19, 2006 7:08 AM > To: Wrightson,A,Ann,JPGA8Y C > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Simplicity of XML > >> And a simple description of cyclomatic complexity, that despite its >> offputting name could be adapted to give a nice metric for the degree >> of optionality expressed in a schema: >> >> http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html > > > this is interesting. > > First a comment about cyclomatic complexity and code. One of the leading > programmers I have worked with was a master at reducing cyclomatic > complexity. It was unusual to see him do anything over 4. All fine, but > he produced a litany of classes with a litany of methods on each. It > gets harder and harder to work with this; complexity exists and if you > push it down in one guise, it will reappear in another. > > how might one adapt this to schema? I don't see anything analogous. > count the number of optional attributes and elements? What will this > give us? > > Grahame > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Wed Jul 19 14:12:51 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Wed, 19 Jul 2006 23:12:51 +1000 Subject: [New-ITS] Element content vs attributes In-Reply-To: <849288029444F74899F8C8E3D479FF6DA83C7C@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA83C7C@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BE2FD3.9090601@kestral.com.au> if only xml had introduced as a shorthand for close the current element.... Maybe I'm inclined to agree here. would any else like to comment on this? Grahame ann.wrightson at bt.com wrote: > My own opinion: > > Conveying meaning by arranging content *in* a suitable structure of > well-named elements is at the heart of XML, and using XML in a way that > doesn't work like that is ugly misuse. Attributes are, from this > perspective, metadata on elements, saying something about the element > (or what needs to be done with it, etc) rather than constituting the > element. > > Message size is a matter of optimization,and like all optimizations > should be thought about after lots of other stuff is right, not at the > start. > > Ann W. > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From rik.smithies at cfh.nhs.uk Wed Jul 19 14:21:25 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Wed, 19 Jul 2006 14:21:25 +0100 Subject: [New-ITS] Element content vs attributes Message-ID: <1A3D105C334EAE49BDDD93D8767573F504004EDE@EXCHAQ2.nhsia.nhs.uk> Strikes me that we are now in the optimization phase. Rik > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 19 July 2006 14:13 > To: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Element content vs attributes > > if only xml had introduced as a shorthand for close the > current element.... > > Maybe I'm inclined to agree here. would any else like to > comment on this? > > Grahame > > > ann.wrightson at bt.com wrote: > > My own opinion: > > > > Conveying meaning by arranging content *in* a suitable structure of > > well-named elements is at the heart of XML, and using XML in a way > > that doesn't work like that is ugly misuse. Attributes > are, from this > > perspective, metadata on elements, saying something about > the element > > (or what needs to be done with it, etc) rather than > constituting the > > element. > > > > Message size is a matter of optimization,and like all optimizations > > should be thought about after lots of other stuff is right, > not at the > > start. > > > > Ann W. > > _______________________________________________ > > New-ITS mailing list > > New-ITS at lists.hl7.org.uk > > http://lists.hl7.org.uk/mailman/listinfo/new-its > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. From Charlie at ramseysystems.co.uk Wed Jul 19 15:03:03 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Wed, 19 Jul 2006 15:03:03 +0100 Subject: [New-ITS] Types vs elements vs attributes -- was -- RE: Element content vs attributes Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB6A@ramseysc1420.RamseyNet.local> All I agree with Rik that we are at the optimisation stage (in terms of this particular question), and would further suggest that the data/metadata split very hard to pin down. However I really like the idea of "conveying meaning by arranging content in a suitable structure of well-named ..." where I would take the well named components to be elements and attributes. I find it interesting (and somewhat attractive) that this leaves referencing named types in the instance as "ugly misuse" of XML. All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Smithies Rik > Sent: 19 July 2006 14:21 > To: grahame at jivamedical.com; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Element content vs attributes > > > Strikes me that we are now in the optimization phase. > Rik > > > > -----Original Message----- > > From: new-its-bounces at lists.hl7.org.uk > > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of > Grahame Grieve > > Sent: 19 July 2006 14:13 > > To: new-its at lists.hl7.org.uk > > Subject: Re: [New-ITS] Element content vs attributes > > > > if only xml had introduced as a shorthand for close the current > > element.... > > > > Maybe I'm inclined to agree here. would any else like to comment on > > this? > > > > Grahame > > > > > > ann.wrightson at bt.com wrote: > > > My own opinion: > > > > > > Conveying meaning by arranging content *in* a suitable > structure of > > > well-named elements is at the heart of XML, and using XML > in a way > > > that doesn't work like that is ugly misuse. Attributes > > are, from this > > > perspective, metadata on elements, saying something about > > the element > > > (or what needs to be done with it, etc) rather than > > constituting the > > > element. > > > > > > Message size is a matter of optimization,and like all > optimizations > > > should be thought about after lots of other stuff is right, > > not at the > > > start. > > > > > > Ann W. > > > _______________________________________________ > > > New-ITS mailing list > > > New-ITS at lists.hl7.org.uk > > > http://lists.hl7.org.uk/mailman/listinfo/new-its > > > > > > > -- > > Grahame Grieve > > CTO, Jiva Medical Software Integration Tools > > CTO, Kestral Computing Healthcare Applications > > _______________________________________________ > > New-ITS mailing list > > New-ITS at lists.hl7.org.uk > > http://lists.hl7.org.uk/mailman/listinfo/new-its > > > > This e-mail is confidential and privileged. If you are not > the intended recipient please accept our apologies; please do > not disclose, copy or distribute information in this e-mail > or take any action in reliance on its contents: to do so is > strictly prohibited and may be unlawful. Please inform us > that this message has gone astray before deleting it. Thank > you for your co-operation. > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From ann.wrightson at bt.com Wed Jul 19 15:43:12 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Wed, 19 Jul 2006 15:43:12 +0100 Subject: [New-ITS] Simplicity of XML Message-ID: <849288029444F74899F8C8E3D479FF6DA83DD3@E03MVZ3-UKDY.domain1.systemhost.net> Will think about this. Ann W. -----Original Message----- From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame Grieve Sent: Wednesday, July 19, 2006 2:11 PM To: Wrightson,A,Ann,JPGA8Y C Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Simplicity of XML interesting. how about the (square or optional elements + attributes) / #types (where #types includes named and anonymous and element and group refs are dereferenced, and optional refers to 0..1, not 0..*, or 1..1 with nillable flag) Grahame ann.wrightson at bt.com wrote: > Grahame, > > I'm looking for a suitable surrogate measure for the rather vague > concept of how diverse (in ways that matter) is the class of instances > that schema-validates against a given schema, that itself is a > surrogate for the usability property of "how predictable is this kind > of stuff to process". Stepping back a little, I'm looking for ways to > characterize more exactly the kind of simplicity that we're trying to > achieve; I'm certain there are multiple dimensions and that there will > be multiple trade-offs between them. > > I'm also looking (unsuccessfully so far) for useful background on > mediating between close-to-business & analytically-abstract modelling > (i.e. mediating explicitly rather than talking about whether to do one > or the other, deciding, then building models & stuff). > > Cheers > > Ann W. > > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame > Grieve > Sent: Wednesday, July 19, 2006 7:08 AM > To: Wrightson,A,Ann,JPGA8Y C > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Simplicity of XML > >> And a simple description of cyclomatic complexity, that despite its >> offputting name could be adapted to give a nice metric for the degree >> of optionality expressed in a schema: >> >> http://www.onjava.com/pub/a/onjava/2004/06/16/ccunittest.html > > > this is interesting. > > First a comment about cyclomatic complexity and code. One of the > leading programmers I have worked with was a master at reducing > cyclomatic complexity. It was unusual to see him do anything over 4. > All fine, but he produced a litany of classes with a litany of methods > on each. It gets harder and harder to work with this; complexity > exists and if you push it down in one guise, it will reappear in another. > > how might one adapt this to schema? I don't see anything analogous. > count the number of optional attributes and elements? What will this > give us? > > Grahame > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Thu Jul 20 01:21:16 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 20 Jul 2006 10:21:16 +1000 Subject: [New-ITS] Types vs elements vs attributes -- was -- RE: Element content vs attributes In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FB6A@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FB6A@ramseysc1420.RamseyNet.local> Message-ID: <44BECC7C.90109@kestral.com.au> > However I really like the idea of "conveying meaning by arranging > content in a suitable structure of well-named ..." where I would take > the well named components to be elements and attributes. I find it > interesting (and somewhat attractive) that this leaves referencing named > types in the instance as "ugly misuse" of XML. neatly crossing threads here. I'd be happy for some opinions on this matter. If there is a pattern for polymorphism, how would you best implement it in XML? xsi:type doesn't seem too bad to me, as long is it was either mandatory or excluded, not optional.... Grahame From grahame at kestral.com.au Thu Jul 20 01:23:23 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 20 Jul 2006 10:23:23 +1000 Subject: [New-ITS] extensibility In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FD0C@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1FD0C@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BECCFB.2050302@kestral.com.au> thanks Ann. I liked the formulation. Joe & Col: you guys spoke several times about extensibility a couple of weeks ago. Can you contribute here - what did you have in mind? Grahame ann.wrightson at bt.com wrote: > Grahame, > > It means different things to different people, as ever. > > Business/political level: > > At worst a demand for extensibility means "we must be able to sign up to > this standard without changing any of what we already do..."; not much > better is when it's just a way to get signoff across a group who each > want their own options in (& forget that interoperation means they'll > have to accept & process everyone else's options). A formulation that I > find works well to get the point across when I'm presenting this kind of > stuff is "My extensions & variations help me; everyone else's extensions > & variations hinder me; since I am a minority, what probably helps me > most is to have no extensions or variations at all" ...unless of course > I only interoperate with people I control...which is probably what many > adopters actually want to do :) > > Technical level: > > There appears to be a quasi-religious difference between those who > prefer their extensibility inheritance-style, as the ability to refine > and add into what is given, and those who prefer their extensibility > component-style, where unchangeable components of useful size (not too > large, not too small) can be selected and rearranged as required, and > new components created for new needs. I believe the former is more > congenial for modelling, and the latter more practical for > version-managing and configuration-managing an ongoing corpus of stuff > of whatever kind. > > There's also the characteristic of being modular and separating > concerns, informally: > - I can adopt just the stuff I need without too much brainache, special > setup or performance overhead > - if I need more later, it's an easy upgrade (and doesn't break the old > stuff I need to keep) > - my standard doesn't mess up your standard when they're used together > > > Ann W. > > > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: Wednesday, July 19, 2006 4:15 AM > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] extensibility > > hi Ann > > I am working my way through the many documents you have referred to. > > One subject that's come up a few times is extensibility. > People want it, HL7 may or may not provide it. > > What does it mean? > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Thu Jul 20 06:27:00 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 20 Jul 2006 15:27:00 +1000 Subject: [New-ITS] namespace abbreviations Message-ID: <44BF1424.9070508@kestral.com.au> Would any one like to comment on the idea that the standard should fix the namespace abbreviations used in the instances? Several of the NDR's I have read do this, but it is foreign to my thinking. Grahame From ann.wrightson at bt.com Thu Jul 20 09:49:47 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Thu, 20 Jul 2006 09:49:47 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) Message-ID: <849288029444F74899F8C8E3D479FF6DA840BF@E03MVZ3-UKDY.domain1.systemhost.net> A fork on the previous discussion: GG> I am left with a simple view: attributes are better cause they use less space, so use them when you can. If you package a non-XML data structure into XML in two ways, first using a general rule of put-data-attributes-into-XML-attributes, then using a general rule of put-data-attributes-into-XML-child-elements, then yes XML attributes do use less space. However, if you allow translations that are more intelligent with respect to the nature of XML (for example, removing the constraint that all names and values in the abstractly-modelled non-XML data have to appear unchanged in the XML, including a short readable code-system-name in the implementable model, and thus allowing an OID to yield a readable tagname), an element-based style is able to be both readable and compact - and could still be generated from the non-XML model. Such intelligence does have some cost; I would justify that by saying it's for the same reason as terminologies don't just use code-numbers - people, developers no less than clinicians, need clear-text linguistic forms of reasonable reliability and not just formally-unambiguous gobbledegook. For example (from MIM 4.1.02): can become: summary report without the total loss of signal in the XML regarding the terminology being used that happens if you instead go to this kind of style (MIM 4.1.03): The "loss of signal" for implementers has emerged as the main practical issue here, IMO. However, assuming that all the names involved are about the same length, there is also some difference in the right direction in overall length. At its simplest this is eg: becoming: xxxx The second also shortens by one step the XPath required to select this specific kind of element (and may reduce the size of an intermediate nodeset considerably). Of course, that also means it lengthens the XPath required to find all the XML elements corresponding to type "aaaa" in the underlying model... So as usual we are in a trade-off & need to judge which weighs heavier for our "market". Ann W. From grahame at kestral.com.au Thu Jul 20 10:27:41 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Thu, 20 Jul 2006 19:27:41 +1000 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <849288029444F74899F8C8E3D479FF6DA840BF@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA840BF@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BF4C8D.5050503@kestral.com.au> I will respond to this several times in different ways. One of the things that this makes think is that we should dust off RUIDs. The HL7 type UID is either UUID, OID, or RUID. We've never defined any RUIDs, so no one really talks about them. But we (HL7) could - we could define snomed-CT = [some long oid] loinc = (some long oid) [all HL7 codesets names] = (hl7 oids) other common candidates as required then you could have (This doesn't address the xml issues - I Will take them up separately.) But is this change something that would make the messages more friendly? Actually, it's possible that the UK realm could just define these without lengthy consultation with HL7 under realm localisation. The comments in the abstract data types say: "A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations" ambiguous where a realm sits here. We could seek clarification. But this is only worthwhile if getting rid of the oids would be friendly. comments? Grahame ann.wrightson at bt.com wrote: > A fork on the previous discussion: > > GG> I am left with a simple view: attributes are better cause they use > less space, so use them when you can. > > If you package a non-XML data structure into XML in two ways, first > using a general rule of put-data-attributes-into-XML-attributes, then > using a general rule of put-data-attributes-into-XML-child-elements, > then yes XML attributes do use less space. > > However, if you allow translations that are more intelligent with > respect to the nature of XML (for example, removing the constraint that > all names and values in the abstractly-modelled non-XML data have to > appear unchanged in the XML, including a short readable code-system-name > in the implementable model, and thus allowing an OID to yield a readable > tagname), an element-based style is able to be both readable and compact > - and could still be generated from the non-XML model. Such intelligence > does have some cost; I would justify that by saying it's for the same > reason as terminologies don't just use code-numbers - people, developers > no less than clinicians, need clear-text linguistic forms of reasonable > reliability and not just formally-unambiguous gobbledegook. > > For example (from MIM 4.1.02): > > displayName="summary report" /> > > can become: > > summary report > > without the total loss of signal in the XML regarding the terminology > being used that happens if you instead go to this kind of style (MIM > 4.1.03): > > > > The "loss of signal" for implementers has emerged as the main practical > issue here, IMO. However, assuming that all the names involved are about > the same length, there is also some difference in the right direction in > overall length. At its simplest this is eg: > > > > becoming: > > xxxx > > The second also shortens by one step the XPath required to select this > specific kind of element (and may reduce the size of an intermediate > nodeset considerably). Of course, that also means it lengthens the XPath > required to find all the XML elements corresponding to type "aaaa" in > the underlying model... So as usual we are in a trade-off & need to > judge which weighs heavier for our "market". > > Ann W. > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Thu Jul 20 12:48:35 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Thu, 20 Jul 2006 12:48:35 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <44BF4C8D.5050503@kestral.com.au> Message-ID: The question is whether getting rid of OIDs would be friendly? This raises several related questions. Are people so familiar with oids that they would miss them? In teaching HL7 I have not met anyone who was familiar with OIDs outside of HL7. Can we can do what we want without using OIDs? If OIDs did not already exist today, is there is a real user requirement to invent them? I think that the answers to the last 2 questions are probably YES and NO respectively Tim On 20/7/06 10:27 Grahame Grieve wrote: > I will respond to this several times in different ways. One of the things > that this makes think is that we should dust off RUIDs. The HL7 type UID > is either UUID, OID, or RUID. We've never defined any RUIDs, so no one really > talks about them. But we (HL7) could - we could define > > snomed-CT = [some long oid] > loinc = (some long oid) > [all HL7 codesets names] = (hl7 oids) > other common candidates as required > > then you could have > > (This doesn't address the xml issues - I Will take them up separately.) > > But is this change something that would make the messages more friendly? > > Actually, it's possible that the UK realm could just define these without > lengthy consultation with HL7 under realm localisation. The comments in > the abstract data types say: > > "A globally unique string defined exclusively by HL7. Identifiers in > this scheme are only defined by balloted HL7 specifications. Local > communities or systems must never use such reserved identifiers > based on bilateral negotiations" > > ambiguous where a realm sits here. We could seek clarification. But this > is only worthwhile if getting rid of the oids would be friendly. > > comments? > > Grahame > > > ann.wrightson at bt.com wrote: >> A fork on the previous discussion: >> >> GG> I am left with a simple view: attributes are better cause they use >> less space, so use them when you can. >> >> If you package a non-XML data structure into XML in two ways, first >> using a general rule of put-data-attributes-into-XML-attributes, then >> using a general rule of put-data-attributes-into-XML-child-elements, >> then yes XML attributes do use less space. >> >> However, if you allow translations that are more intelligent with >> respect to the nature of XML (for example, removing the constraint that >> all names and values in the abstractly-modelled non-XML data have to >> appear unchanged in the XML, including a short readable code-system-name >> in the implementable model, and thus allowing an OID to yield a readable >> tagname), an element-based style is able to be both readable and compact >> - and could still be generated from the non-XML model. Such intelligence >> does have some cost; I would justify that by saying it's for the same >> reason as terminologies don't just use code-numbers - people, developers >> no less than clinicians, need clear-text linguistic forms of reasonable >> reliability and not just formally-unambiguous gobbledegook. >> >> For example (from MIM 4.1.02): >> >> > displayName="summary report" /> >> >> can become: >> >> summary report >> >> without the total loss of signal in the XML regarding the terminology >> being used that happens if you instead go to this kind of style (MIM >> 4.1.03): >> >> >> >> The "loss of signal" for implementers has emerged as the main practical >> issue here, IMO. However, assuming that all the names involved are about >> the same length, there is also some difference in the right direction in >> overall length. At its simplest this is eg: >> >> >> >> becoming: >> >> xxxx >> >> The second also shortens by one step the XPath required to select this >> specific kind of element (and may reduce the size of an intermediate >> nodeset considerably). Of course, that also means it lengthens the XPath >> required to find all the XML elements corresponding to type "aaaa" in >> the underlying model... So as usual we are in a trade-off & need to >> judge which weighs heavier for our "market". >> >> Ann W. >> From ann.wrightson at bt.com Thu Jul 20 16:42:38 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Thu, 20 Jul 2006 16:42:38 +0100 Subject: [New-ITS] I'm away for a while Message-ID: <849288029444F74899F8C8E3D479FF6DA84669@E03MVZ3-UKDY.domain1.systemhost.net> After today I am in events and travelling for most of the next three weeks, so will be participating now & then only. Just so's you know I haven't lose interest... Cheers Ann W. From ann.wrightson at bt.com Thu Jul 20 16:42:21 2006 From: ann.wrightson at bt.com (ann.wrightson@bt.com) Date: Thu, 20 Jul 2006 16:42:21 +0100 Subject: [New-ITS] Java validation (was: RE: Schemas for Validation??) Message-ID: <849288029444F74899F8C8E3D479FF6DA8466A@E03MVZ3-UKDY.domain1.systemhost.net> Here is a response from Inigo Surguy (inigo.surguy at csw.co.uk): Compared to W3C XML Schema, I agree that many approaches can provide better validation, and if that was the only option, then I would agree that Java validation would be a reasonable choice. However, I think it makes more sense to use Schematron as a validation language rather than Java. The pros of the Java validation approach are all pros of Schematron, too (except probably the speed), and Schematron is easier to write, and more generally supported. With the Java approach, you still need some way of specifying the constraints that will be applied to the document, and the most obvious choice is to use XPath. Then, it makes sense for the XPaths to be held in a properties file so they can be changed without recompilation, and it makes sense to associate an error message with each XPath as well. Go any distance down this route and you end up reinventing Schematron! The only significant reason I can see for using Java over Schematron is for memory and performance efficiency. Constraints can be checked using a streaming Java SAX implementation without having to read the entire HL7 document into memory, which allows very large documents to be handled without problems. Empirically, I found during PSIS development that reading HL7 via SAX and validating it with some simple constraints written in Java was about twice as fast as doing the same via Java using XPath. A Schematron implementation would be slower again than Java+XPath. However, I don't consider the performance benefit a viable reason for choosing Java over another validator. When I was working on PSIS, I did write a simple Java HL7 validator. However, this worked by applying a W3C Schema, and a Schematron schema. The Java code made it easy to apply it to multiple messages simultaneously, and the Schematron made it easy to write the validation code. The Schematron code was using XSLT 2 Schematron (and hence had regex support, etc.) with some XSLT 2 functions to abstract common checks. This worked well, and non-Java programmers were able to extend it and improve it. This is the approach I recommend - using Schematron to write the validation rules, and Java (.NET, whatever) to apply the validation. I think this suits the strengths of both languages. In addition - for those constraints which are difficult to express in Schematron, then you can use Java extension functions from within the XSLT Schematron implementation. As long as the definition of these extensions is clear, then they could equally well be implemented in .NET, or pure XSLT, or any other language - see the EXSLT project for an example of this approach. Cheers Inigo From grahame at kestral.com.au Thu Jul 20 16:55:02 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 21 Jul 2006 01:55:02 +1000 Subject: [New-ITS] Java validation (was: RE: Schemas for Validation??) In-Reply-To: <849288029444F74899F8C8E3D479FF6DA8466A@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA8466A@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BFA756.9090901@kestral.com.au> interesting points. What makes the difference is the availability of extra schematic information in various files that would be brought be bear - MIF, XMI, abstract constraints, etc the other important thing is the use of the extensions to provide terminology. Grahame ann.wrightson at bt.com wrote: > Here is a response from Inigo Surguy (inigo.surguy at csw.co.uk): > > Compared to W3C XML Schema, I agree that many approaches can provide > better validation, and if that was the only option, then I would agree > that Java validation would be a reasonable choice. > > However, I think it makes more sense to use Schematron as a validation > language rather than Java. The pros of the Java validation approach are > all pros of Schematron, too (except probably the speed), and Schematron > is easier to write, and more generally supported. > > With the Java approach, you still need some way of specifying the > constraints that will be applied to the document, and the most obvious > choice is to use XPath. Then, it makes sense for the XPaths to be held > in a properties file so they can be changed without recompilation, and > it makes sense to associate an error message with each XPath as well. Go > any distance down this route and you end up reinventing Schematron! > > The only significant reason I can see for using Java over Schematron is > for memory and performance efficiency. Constraints can be checked using > a streaming Java SAX implementation without having to read the entire > HL7 document into memory, which allows very large documents to be > handled without problems. Empirically, I found during PSIS development > that reading HL7 via SAX and validating it with some simple constraints > written in Java was about twice as fast as doing the same via Java using > XPath. A Schematron implementation would be slower again than > Java+XPath. However, I don't consider the performance benefit a viable > reason for choosing Java over another validator. > > When I was working on PSIS, I did write a simple Java HL7 validator. > However, this worked by applying a W3C Schema, and a Schematron schema. > The Java code made it easy to apply it to multiple messages > simultaneously, and the Schematron made it easy to write the validation > code. The Schematron code was using XSLT 2 Schematron (and hence had > regex support, etc.) with some XSLT 2 functions to abstract common > checks. This worked well, and non-Java programmers were able to extend > it and improve it. > > This is the approach I recommend - using Schematron to write the > validation rules, and Java (.NET, whatever) to apply the validation. I > think this suits the strengths of both languages. In addition - for > those constraints which are difficult to express in Schematron, then you > can use Java extension functions from within the XSLT Schematron > implementation. As long as the definition of these extensions is clear, > then they could equally well be implemented in .NET, or pure XSLT, or > any other language - see the EXSLT project for an example of this > approach. > > Cheers > > Inigo > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Thu Jul 20 18:21:25 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 21 Jul 2006 03:21:25 +1000 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <849288029444F74899F8C8E3D479FF6DA840BF@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA840BF@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44BFBB95.4010907@kestral.com.au> > For example (from MIM 4.1.02): > > displayName="summary report" /> > > can become: > > summary report this has some cost, this idea. there's the cost of figuring out the name transform from a non-name property, and the cost of managing the name uniqueness requirements. I'd rather use RUIDs than this approach because of those costs. Grahame From tim.benson at abies.co.uk Thu Jul 20 19:12:03 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Thu, 20 Jul 2006 19:12:03 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <44BFBB95.4010907@kestral.com.au> Message-ID: I confess I had never really looked into RUIDs before. For those like me, the entire reference in Data Types - Abstract Specification Edition 2006 is: 2.16 HL7 Reserved Identifier Scheme (RUID) specializes UID Definition: A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations. HL7 reserved identifiers are strings that consist only of (US-ASCII) letters, digits and hyphens, where the first character must be a letter. HL7 may assign these reserved identifiers as mnemonic identifiers for major concepts of interest to HL7. Tim On 20/7/06 18:21 Grahame Grieve wrote: >> For example (from MIM 4.1.02): >> >> > displayName="summary report" /> >> >> can become: >> >> summary report > > this has some cost, this idea. there's the cost of figuring out the > name transform from a non-name property, and the cost of managing > the name uniqueness requirements. > > I'd rather use RUIDs than this approach because of those costs. > > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > From GJEWELL at CERNER.COM Thu Jul 20 19:21:35 2006 From: GJEWELL at CERNER.COM (Jewell,Gaby) Date: Thu, 20 Jul 2006 13:21:35 -0500 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) Message-ID: <19FA77FD170347429EC43D7F4CDB198C035A3EFA@MSMBWHQ10.northamerica.cerner.net> Thank you Tim! Am always glad to know I'm not the only one who keeps hearing new language. And I thought I had read the abstract data types often enough in regards to UIDs.... Gaby Jewell | Strategist | Cerner Corporation | office: 816.201.3290 | fax: 816.571.3290 | gjewell at cerner.com | www.cerner.com -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson Sent: Thursday, July 20, 2006 1:12 PM To: grahame at jivamedical.com; ann.wrightson at bt.com Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Compactness of style (was: RE: Element content vs attributes) I confess I had never really looked into RUIDs before. For those like me, the entire reference in Data Types - Abstract Specification Edition 2006 is: 2.16 HL7 Reserved Identifier Scheme (RUID) specializes UID Definition: A globally unique string defined exclusively by HL7. Identifiers in this scheme are only defined by balloted HL7 specifications. Local communities or systems must never use such reserved identifiers based on bilateral negotiations. HL7 reserved identifiers are strings that consist only of (US-ASCII) letters, digits and hyphens, where the first character must be a letter. HL7 may assign these reserved identifiers as mnemonic identifiers for major concepts of interest to HL7. Tim On 20/7/06 18:21 Grahame Grieve wrote: >> For example (from MIM 4.1.02): >> >> > displayName="summary report" /> >> >> can become: >> >> summary report > > this has some cost, this idea. there's the cost of figuring out the > name transform from a non-name property, and the cost of managing the > name uniqueness requirements. > > I'd rather use RUIDs than this approach because of those costs. > > Grahame > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its ----------------------------------------- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. ------------------------------------------- From rik.smithies at cfh.nhs.uk Fri Jul 21 12:06:01 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Fri, 21 Jul 2006 12:06:01 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) Message-ID: <1A3D105C334EAE49BDDD93D8767573F5040055BB@EXCHAQ2.nhsia.nhs.uk> Hi Tim, Grahame > Can we can do what we want without using OIDs? > > If OIDs did not already exist today, is there is a real user > requirement to invent them? > > I think that the answers to the last 2 questions are probably > YES and NO respectively I would have suggested NO and YES, so what are the alternatives ? You seem to need a namespacing method for codes and ids, hierarchical ideally, to ease sub-allocation, so OIDs work pretty well imho. They are verbose unfortunately. They also don't cover the requirement to say what type of ID something is. UUIDs are also very verbose. You could certainly shrink messages a few percent by using a more compressed UUID format (eg base 36). They stick out like a sore thumb in flattened versions of current ITS examples. I once looked for an alternative and nothing came up. I like the idea of RUIDs, which I have also never seen before. But if in a given model a certain attribute is always, say, SCT, then there is no theoretical need to send the codeSystem all, hence no great advantage in shortening it. There is also the CodeSystemName if you want readability. The casual reader of XML will just see it's a code and read the displayName. It don't believe it help readability to the non-expert to have the OID shown in "english" as an RUID, it would be best to just have code and text. If the OID must be carried for some other reason, then if the RUID is shorter so much the better, but two formats are harder to support than one and OIDs aren't likely to disappear totally. Rik > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson > Sent: 20 July 2006 12:49 > To: grahame at jivamedical.com; ann.wrightson at bt.com > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Compactness of style (was: RE: Element > content vs attributes) > > The question is whether getting rid of OIDs would be > friendly? This raises several related questions. > > Are people so familiar with oids that they would miss them? > In teaching HL7 I have not met anyone who was familiar with > OIDs outside of HL7. > > Can we can do what we want without using OIDs? > > If OIDs did not already exist today, is there is a real user > requirement to invent them? > > I think that the answers to the last 2 questions are probably > YES and NO respectively > > Tim > > On 20/7/06 10:27 Grahame Grieve wrote: > > > I will respond to this several times in different ways. One of the > > things that this makes think is that we should dust off > RUIDs. The HL7 > > type UID is either UUID, OID, or RUID. We've never defined > any RUIDs, > > so no one really talks about them. But we (HL7) could - we could > > define > > > > snomed-CT = [some long oid] > > loinc = (some long oid) > > [all HL7 codesets names] = (hl7 oids) > > other common candidates as required > > > > then you could have > > > > (This doesn't address the xml issues - I Will take them up > > separately.) > > > > But is this change something that would make the messages > more friendly? > > > > Actually, it's possible that the UK realm could just define these > > without lengthy consultation with HL7 under realm localisation. The > > comments in the abstract data types say: > > > > "A globally unique string defined exclusively by HL7. > Identifiers in > > this scheme are only defined by balloted HL7 > specifications. Local > > communities or systems must never use such reserved identifiers > > based on bilateral negotiations" > > > > ambiguous where a realm sits here. We could seek clarification. But > > this is only worthwhile if getting rid of the oids would be > friendly. > > > > comments? > > > > Grahame > > > > > > ann.wrightson at bt.com wrote: > >> A fork on the previous discussion: > >> > >> GG> I am left with a simple view: attributes are better cause they > >> GG> use > >> less space, so use them when you can. > >> > >> If you package a non-XML data structure into XML in two > ways, first > >> using a general rule of > put-data-attributes-into-XML-attributes, then > >> using a general rule of > put-data-attributes-into-XML-child-elements, > >> then yes XML attributes do use less space. > >> > >> However, if you allow translations that are more intelligent with > >> respect to the nature of XML (for example, removing the constraint > >> that all names and values in the abstractly-modelled non-XML data > >> have to appear unchanged in the XML, including a short readable > >> code-system-name in the implementable model, and thus > allowing an OID > >> to yield a readable tagname), an element-based style is able to be > >> both readable and compact > >> - and could still be generated from the non-XML model. Such > >> intelligence does have some cost; I would justify that by > saying it's > >> for the same reason as terminologies don't just use code-numbers - > >> people, developers no less than clinicians, need clear-text > >> linguistic forms of reasonable reliability and not just > formally-unambiguous gobbledegook. > >> > >> For example (from MIM 4.1.02): > >> > >> >> displayName="summary report" /> > >> > >> can become: > >> > >> summary report > >> > >> without the total loss of signal in the XML regarding the > terminology > >> being used that happens if you instead go to this kind of > style (MIM > >> 4.1.03): > >> > >> > >> > >> The "loss of signal" for implementers has emerged as the main > >> practical issue here, IMO. However, assuming that all the names > >> involved are about the same length, there is also some > difference in > >> the right direction in overall length. At its simplest this is eg: > >> > >> > >> > >> becoming: > >> > >> xxxx > >> > >> The second also shortens by one step the XPath required to select > >> this specific kind of element (and may reduce the size of an > >> intermediate nodeset considerably). Of course, that also means it > >> lengthens the XPath required to find all the XML elements > >> corresponding to type "aaaa" in the underlying model... So > as usual > >> we are in a trade-off & need to judge which weighs heavier > for our "market". > >> > >> Ann W. > >> > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. From grahame at kestral.com.au Fri Jul 21 13:21:42 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 21 Jul 2006 22:21:42 +1000 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F5040055BB@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F5040055BB@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44C0C6D6.3070306@kestral.com.au> that's right, the ruids are just token replacements for oids, so oids are still there in the background. I'm a little pessimistic that we can remove the codeSystem from the instance. The reason is the difference between valueSet and codeSystem - is there good machinery to infer that valueSet X with CWE means that the implementable model can regard the codeSystem as fixed? Grahame Smithies Rik wrote: > Hi Tim, Grahame > > >> Can we can do what we want without using OIDs? >> >> If OIDs did not already exist today, is there is a real user >> requirement to invent them? >> >> I think that the answers to the last 2 questions are probably >> YES and NO respectively > > I would have suggested NO and YES, so what are the alternatives ? You > seem to need a namespacing method for codes and ids, hierarchical > ideally, to ease sub-allocation, so OIDs work pretty well imho. They are > verbose unfortunately. They also don't cover the requirement to say what > type of ID something is. > > UUIDs are also very verbose. You could certainly shrink messages a few > percent by using a more compressed UUID format (eg base 36). They stick > out like a sore thumb in flattened versions of current ITS examples. I > once looked for an alternative and nothing came up. > > I like the idea of RUIDs, which I have also never seen before. But if in > a given model a certain attribute is always, say, SCT, then there is no > theoretical need to send the codeSystem all, hence no great advantage in > shortening it. > > There is also the CodeSystemName if you want readability. The casual > reader of XML will just see it's a code and read the displayName. It > don't believe it help readability to the non-expert to have the OID > shown in "english" as an RUID, it would be best to just have code and > text. > > If the OID must be carried for some other reason, then if the RUID is > shorter so much the better, but two formats are harder to support than > one and OIDs aren't likely to disappear totally. > > Rik > >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson >> Sent: 20 July 2006 12:49 >> To: grahame at jivamedical.com; ann.wrightson at bt.com >> Cc: new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Compactness of style (was: RE: Element >> content vs attributes) >> >> The question is whether getting rid of OIDs would be >> friendly? This raises several related questions. >> >> Are people so familiar with oids that they would miss them? >> In teaching HL7 I have not met anyone who was familiar with >> OIDs outside of HL7. >> >> Can we can do what we want without using OIDs? >> >> If OIDs did not already exist today, is there is a real user >> requirement to invent them? >> >> I think that the answers to the last 2 questions are probably >> YES and NO respectively >> >> Tim >> >> On 20/7/06 10:27 Grahame Grieve wrote: >> >>> I will respond to this several times in different ways. One of the >>> things that this makes think is that we should dust off >> RUIDs. The HL7 >>> type UID is either UUID, OID, or RUID. We've never defined >> any RUIDs, >>> so no one really talks about them. But we (HL7) could - we could >>> define >>> >>> snomed-CT = [some long oid] >>> loinc = (some long oid) >>> [all HL7 codesets names] = (hl7 oids) >>> other common candidates as required >>> >>> then you could have >>> >>> (This doesn't address the xml issues - I Will take them up >>> separately.) >>> >>> But is this change something that would make the messages >> more friendly? >>> Actually, it's possible that the UK realm could just define these >>> without lengthy consultation with HL7 under realm localisation. The >>> comments in the abstract data types say: >>> >>> "A globally unique string defined exclusively by HL7. >> Identifiers in >>> this scheme are only defined by balloted HL7 >> specifications. Local >>> communities or systems must never use such reserved identifiers >>> based on bilateral negotiations" >>> >>> ambiguous where a realm sits here. We could seek clarification. But >>> this is only worthwhile if getting rid of the oids would be >> friendly. >>> comments? >>> >>> Grahame >>> >>> >>> ann.wrightson at bt.com wrote: >>>> A fork on the previous discussion: >>>> >>>> GG> I am left with a simple view: attributes are better cause they >>>> GG> use >>>> less space, so use them when you can. >>>> >>>> If you package a non-XML data structure into XML in two >> ways, first >>>> using a general rule of >> put-data-attributes-into-XML-attributes, then >>>> using a general rule of >> put-data-attributes-into-XML-child-elements, >>>> then yes XML attributes do use less space. >>>> >>>> However, if you allow translations that are more intelligent with >>>> respect to the nature of XML (for example, removing the constraint >>>> that all names and values in the abstractly-modelled non-XML data >>>> have to appear unchanged in the XML, including a short readable >>>> code-system-name in the implementable model, and thus >> allowing an OID >>>> to yield a readable tagname), an element-based style is able to be >>>> both readable and compact >>>> - and could still be generated from the non-XML model. Such >>>> intelligence does have some cost; I would justify that by >> saying it's >>>> for the same reason as terminologies don't just use code-numbers - >>>> people, developers no less than clinicians, need clear-text >>>> linguistic forms of reasonable reliability and not just >> formally-unambiguous gobbledegook. >>>> For example (from MIM 4.1.02): >>>> >>>> >>> displayName="summary report" /> >>>> >>>> can become: >>>> >>>> summary report >>>> >>>> without the total loss of signal in the XML regarding the >> terminology >>>> being used that happens if you instead go to this kind of >> style (MIM >>>> 4.1.03): >>>> >>>> >>>> >>>> The "loss of signal" for implementers has emerged as the main >>>> practical issue here, IMO. However, assuming that all the names >>>> involved are about the same length, there is also some >> difference in >>>> the right direction in overall length. At its simplest this is eg: >>>> >>>> >>>> >>>> becoming: >>>> >>>> xxxx >>>> >>>> The second also shortens by one step the XPath required to select >>>> this specific kind of element (and may reduce the size of an >>>> intermediate nodeset considerably). Of course, that also means it >>>> lengthens the XPath required to find all the XML elements >>>> corresponding to type "aaaa" in the underlying model... So >> as usual >>>> we are in a trade-off & need to judge which weighs heavier >> for our "market". >>>> Ann W. >>>> >> >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> > > This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. > > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From rik.smithies at cfh.nhs.uk Fri Jul 21 13:56:43 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Fri, 21 Jul 2006 13:56:43 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) Message-ID: <1A3D105C334EAE49BDDD93D8767573F50400566E@EXCHAQ2.nhsia.nhs.uk> I may have missed the point, but I was expecting the codeSystem to be only suppressible in cases of CNE. I realised that some models need to be generic and future proof, and in those cases where any codeSystem can come along, you surely do need to say the codeSystem. I'd like to think that serious used of CWE was rare though. Certainly in CFH it isn't used much if at all. Is CWE meant for "send anything you like" or is it where multiple codeSystem are sanctioned, but not all codeSystem, and you just cant narrow it down to one for the diagram ? Or is that the point where valueSets come into play ? What if you allow any code from 2 codeSystem, is that CWE ? Rik > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 21 July 2006 13:22 > To: Smithies Rik > Cc: Tim Benson; grahame at jivamedical.com; > new-its at lists.hl7.org.uk; ann.wrightson at bt.com > Subject: Re: [New-ITS] Compactness of style (was: RE: Element > content vs attributes) > > that's right, the ruids are just token replacements for oids, > so oids are still there in the background. > > I'm a little pessimistic that we can remove the codeSystem > from the instance. The reason is the difference between > valueSet and codeSystem - is there good machinery to infer > that valueSet X with CWE means that the implementable model > can regard the codeSystem as fixed? > > Grahame > > > Smithies Rik wrote: > > Hi Tim, Grahame > > > > > >> Can we can do what we want without using OIDs? > >> > >> If OIDs did not already exist today, is there is a real user > >> requirement to invent them? > >> > >> I think that the answers to the last 2 questions are > probably YES and > >> NO respectively > > > > I would have suggested NO and YES, so what are the > alternatives ? You > > seem to need a namespacing method for codes and ids, hierarchical > > ideally, to ease sub-allocation, so OIDs work pretty well > imho. They > > are verbose unfortunately. They also don't cover the requirement to > > say what type of ID something is. > > > > UUIDs are also very verbose. You could certainly shrink > messages a few > > percent by using a more compressed UUID format (eg base 36). They > > stick out like a sore thumb in flattened versions of current ITS > > examples. I once looked for an alternative and nothing came up. > > > > I like the idea of RUIDs, which I have also never seen > before. But if > > in a given model a certain attribute is always, say, SCT, > then there > > is no theoretical need to send the codeSystem all, hence no great > > advantage in shortening it. > > > > There is also the CodeSystemName if you want readability. > The casual > > reader of XML will just see it's a code and read the > displayName. It > > don't believe it help readability to the non-expert to have the OID > > shown in "english" as an RUID, it would be best to just > have code and > > text. > > > > If the OID must be carried for some other reason, then if > the RUID is > > shorter so much the better, but two formats are harder to > support than > > one and OIDs aren't likely to disappear totally. > > > > Rik > > > >> -----Original Message----- > >> From: new-its-bounces at lists.hl7.org.uk > >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson > >> Sent: 20 July 2006 12:49 > >> To: grahame at jivamedical.com; ann.wrightson at bt.com > >> Cc: new-its at lists.hl7.org.uk > >> Subject: Re: [New-ITS] Compactness of style (was: RE: > Element content > >> vs attributes) > >> > >> The question is whether getting rid of OIDs would be > friendly? This > >> raises several related questions. > >> > >> Are people so familiar with oids that they would miss them? > >> In teaching HL7 I have not met anyone who was familiar with OIDs > >> outside of HL7. > >> > >> Can we can do what we want without using OIDs? > >> > >> If OIDs did not already exist today, is there is a real user > >> requirement to invent them? > >> > >> I think that the answers to the last 2 questions are > probably YES and > >> NO respectively > >> > >> Tim > >> > >> On 20/7/06 10:27 Grahame Grieve wrote: > >> > >>> I will respond to this several times in different ways. > One of the > >>> things that this makes think is that we should dust off > >> RUIDs. The HL7 > >>> type UID is either UUID, OID, or RUID. We've never defined > >> any RUIDs, > >>> so no one really talks about them. But we (HL7) could - we could > >>> define > >>> > >>> snomed-CT = [some long oid] > >>> loinc = (some long oid) > >>> [all HL7 codesets names] = (hl7 oids) other common candidates as > >>> required > >>> > >>> then you could have > >>> > >>> (This doesn't address the xml issues - I Will take them up > >>> separately.) > >>> > >>> But is this change something that would make the messages > >> more friendly? > >>> Actually, it's possible that the UK realm could just define these > >>> without lengthy consultation with HL7 under realm > localisation. The > >>> comments in the abstract data types say: > >>> > >>> "A globally unique string defined exclusively by HL7. > >> Identifiers in > >>> this scheme are only defined by balloted HL7 > >> specifications. Local > >>> communities or systems must never use such reserved identifiers > >>> based on bilateral negotiations" > >>> > >>> ambiguous where a realm sits here. We could seek > clarification. But > >>> this is only worthwhile if getting rid of the oids would be > >> friendly. > >>> comments? > >>> > >>> Grahame > >>> > >>> > >>> ann.wrightson at bt.com wrote: > >>>> A fork on the previous discussion: > >>>> > >>>> GG> I am left with a simple view: attributes are better > cause they > >>>> GG> use > >>>> less space, so use them when you can. > >>>> > >>>> If you package a non-XML data structure into XML in two > >> ways, first > >>>> using a general rule of > >> put-data-attributes-into-XML-attributes, then > >>>> using a general rule of > >> put-data-attributes-into-XML-child-elements, > >>>> then yes XML attributes do use less space. > >>>> > >>>> However, if you allow translations that are more > intelligent with > >>>> respect to the nature of XML (for example, removing the > constraint > >>>> that all names and values in the abstractly-modelled > non-XML data > >>>> have to appear unchanged in the XML, including a short readable > >>>> code-system-name in the implementable model, and thus > >> allowing an OID > >>>> to yield a readable tagname), an element-based style is > able to be > >>>> both readable and compact > >>>> - and could still be generated from the non-XML model. Such > >>>> intelligence does have some cost; I would justify that by > >> saying it's > >>>> for the same reason as terminologies don't just use > code-numbers - > >>>> people, developers no less than clinicians, need clear-text > >>>> linguistic forms of reasonable reliability and not just > >> formally-unambiguous gobbledegook. > >>>> For example (from MIM 4.1.02): > >>>> > >>>> code="371534008" > >>>> displayName="summary report" /> > >>>> > >>>> can become: > >>>> > >>>> summary report > >>>> > >>>> without the total loss of signal in the XML regarding the > >> terminology > >>>> being used that happens if you instead go to this kind of > >> style (MIM > >>>> 4.1.03): > >>>> > >>>> > >>>> > >>>> The "loss of signal" for implementers has emerged as the main > >>>> practical issue here, IMO. However, assuming that all the names > >>>> involved are about the same length, there is also some > >> difference in > >>>> the right direction in overall length. At its simplest > this is eg: > >>>> > >>>> > >>>> > >>>> becoming: > >>>> > >>>> xxxx > >>>> > >>>> The second also shortens by one step the XPath required > to select > >>>> this specific kind of element (and may reduce the size of an > >>>> intermediate nodeset considerably). Of course, that also > means it > >>>> lengthens the XPath required to find all the XML elements > >>>> corresponding to type "aaaa" in the underlying model... So > >> as usual > >>>> we are in a trade-off & need to judge which weighs heavier > >> for our "market". > >>>> Ann W. > >>>> > >> > >> _______________________________________________ > >> New-ITS mailing list > >> New-ITS at lists.hl7.org.uk > >> http://lists.hl7.org.uk/mailman/listinfo/new-its > >> > > > > This e-mail is confidential and privileged. If you are not > the intended recipient please accept our apologies; please do > not disclose, copy or distribute information in this e-mail > or take any action in reliance on its contents: to do so is > strictly prohibited and may be unlawful. Please inform us > that this message has gone astray before deleting it. Thank > you for your co-operation. > > > > > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > From grahame at kestral.com.au Fri Jul 21 13:59:14 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Fri, 21 Jul 2006 22:59:14 +1000 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F50400566E@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F50400566E@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44C0CFA2.5050407@kestral.com.au> CWE says extensions are allowed. The most common case for extensions is when new codes are added for a new version of the codeSystem. CNE means they can't be adopted seamlessly whereas CWE says that they can. For this reason there is agreement at HL7 that snomed is always CWE. But I am not acquainted with CfH thinking on this issue, nor have I looked at the models to see how it's done. Grahame Smithies Rik wrote: > I may have missed the point, but I was expecting the codeSystem to be > only suppressible in cases of CNE. > > I realised that some models need to be generic and future proof, and in > those cases where any codeSystem can come along, you surely do need to > say the codeSystem. > > I'd like to think that serious used of CWE was rare though. Certainly in > CFH it isn't used much if at all. > > Is CWE meant for "send anything you like" or is it where multiple > codeSystem are sanctioned, but not all codeSystem, and you just cant > narrow it down to one for the diagram ? Or is that the point where > valueSets come into play ? What if you allow any code from 2 codeSystem, > is that CWE ? > > Rik > >> -----Original Message----- >> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of >> Grahame Grieve >> Sent: 21 July 2006 13:22 >> To: Smithies Rik >> Cc: Tim Benson; grahame at jivamedical.com; >> new-its at lists.hl7.org.uk; ann.wrightson at bt.com >> Subject: Re: [New-ITS] Compactness of style (was: RE: Element >> content vs attributes) >> >> that's right, the ruids are just token replacements for oids, >> so oids are still there in the background. >> >> I'm a little pessimistic that we can remove the codeSystem >> from the instance. The reason is the difference between >> valueSet and codeSystem - is there good machinery to infer >> that valueSet X with CWE means that the implementable model >> can regard the codeSystem as fixed? >> >> Grahame >> >> >> Smithies Rik wrote: >>> Hi Tim, Grahame >>> >>> >>>> Can we can do what we want without using OIDs? >>>> >>>> If OIDs did not already exist today, is there is a real user >>>> requirement to invent them? >>>> >>>> I think that the answers to the last 2 questions are >> probably YES and >>>> NO respectively >>> I would have suggested NO and YES, so what are the >> alternatives ? You >>> seem to need a namespacing method for codes and ids, hierarchical >>> ideally, to ease sub-allocation, so OIDs work pretty well >> imho. They >>> are verbose unfortunately. They also don't cover the requirement to >>> say what type of ID something is. >>> >>> UUIDs are also very verbose. You could certainly shrink >> messages a few >>> percent by using a more compressed UUID format (eg base 36). They >>> stick out like a sore thumb in flattened versions of current ITS >>> examples. I once looked for an alternative and nothing came up. >>> >>> I like the idea of RUIDs, which I have also never seen >> before. But if >>> in a given model a certain attribute is always, say, SCT, >> then there >>> is no theoretical need to send the codeSystem all, hence no great >>> advantage in shortening it. >>> >>> There is also the CodeSystemName if you want readability. >> The casual >>> reader of XML will just see it's a code and read the >> displayName. It >>> don't believe it help readability to the non-expert to have the OID >>> shown in "english" as an RUID, it would be best to just >> have code and >>> text. >>> >>> If the OID must be carried for some other reason, then if >> the RUID is >>> shorter so much the better, but two formats are harder to >> support than >>> one and OIDs aren't likely to disappear totally. >>> >>> Rik >>> >>>> -----Original Message----- >>>> From: new-its-bounces at lists.hl7.org.uk >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson >>>> Sent: 20 July 2006 12:49 >>>> To: grahame at jivamedical.com; ann.wrightson at bt.com >>>> Cc: new-its at lists.hl7.org.uk >>>> Subject: Re: [New-ITS] Compactness of style (was: RE: >> Element content >>>> vs attributes) >>>> >>>> The question is whether getting rid of OIDs would be >> friendly? This >>>> raises several related questions. >>>> >>>> Are people so familiar with oids that they would miss them? >>>> In teaching HL7 I have not met anyone who was familiar with OIDs >>>> outside of HL7. >>>> >>>> Can we can do what we want without using OIDs? >>>> >>>> If OIDs did not already exist today, is there is a real user >>>> requirement to invent them? >>>> >>>> I think that the answers to the last 2 questions are >> probably YES and >>>> NO respectively >>>> >>>> Tim >>>> >>>> On 20/7/06 10:27 Grahame Grieve wrote: >>>> >>>>> I will respond to this several times in different ways. >> One of the >>>>> things that this makes think is that we should dust off >>>> RUIDs. The HL7 >>>>> type UID is either UUID, OID, or RUID. We've never defined >>>> any RUIDs, >>>>> so no one really talks about them. But we (HL7) could - we could >>>>> define >>>>> >>>>> snomed-CT = [some long oid] >>>>> loinc = (some long oid) >>>>> [all HL7 codesets names] = (hl7 oids) other common candidates as >>>>> required >>>>> >>>>> then you could have >>>>> >>>>> (This doesn't address the xml issues - I Will take them up >>>>> separately.) >>>>> >>>>> But is this change something that would make the messages >>>> more friendly? >>>>> Actually, it's possible that the UK realm could just define these >>>>> without lengthy consultation with HL7 under realm >> localisation. The >>>>> comments in the abstract data types say: >>>>> >>>>> "A globally unique string defined exclusively by HL7. >>>> Identifiers in >>>>> this scheme are only defined by balloted HL7 >>>> specifications. Local >>>>> communities or systems must never use such reserved identifiers >>>>> based on bilateral negotiations" >>>>> >>>>> ambiguous where a realm sits here. We could seek >> clarification. But >>>>> this is only worthwhile if getting rid of the oids would be >>>> friendly. >>>>> comments? >>>>> >>>>> Grahame >>>>> >>>>> >>>>> ann.wrightson at bt.com wrote: >>>>>> A fork on the previous discussion: >>>>>> >>>>>> GG> I am left with a simple view: attributes are better >> cause they >>>>>> GG> use >>>>>> less space, so use them when you can. >>>>>> >>>>>> If you package a non-XML data structure into XML in two >>>> ways, first >>>>>> using a general rule of >>>> put-data-attributes-into-XML-attributes, then >>>>>> using a general rule of >>>> put-data-attributes-into-XML-child-elements, >>>>>> then yes XML attributes do use less space. >>>>>> >>>>>> However, if you allow translations that are more >> intelligent with >>>>>> respect to the nature of XML (for example, removing the >> constraint >>>>>> that all names and values in the abstractly-modelled >> non-XML data >>>>>> have to appear unchanged in the XML, including a short readable >>>>>> code-system-name in the implementable model, and thus >>>> allowing an OID >>>>>> to yield a readable tagname), an element-based style is >> able to be >>>>>> both readable and compact >>>>>> - and could still be generated from the non-XML model. Such >>>>>> intelligence does have some cost; I would justify that by >>>> saying it's >>>>>> for the same reason as terminologies don't just use >> code-numbers - >>>>>> people, developers no less than clinicians, need clear-text >>>>>> linguistic forms of reasonable reliability and not just >>>> formally-unambiguous gobbledegook. >>>>>> For example (from MIM 4.1.02): >>>>>> >>>>>> > code="371534008" >>>>>> displayName="summary report" /> >>>>>> >>>>>> can become: >>>>>> >>>>>> summary report >>>>>> >>>>>> without the total loss of signal in the XML regarding the >>>> terminology >>>>>> being used that happens if you instead go to this kind of >>>> style (MIM >>>>>> 4.1.03): >>>>>> >>>>>> >>>>>> >>>>>> The "loss of signal" for implementers has emerged as the main >>>>>> practical issue here, IMO. However, assuming that all the names >>>>>> involved are about the same length, there is also some >>>> difference in >>>>>> the right direction in overall length. At its simplest >> this is eg: >>>>>> >>>>>> >>>>>> becoming: >>>>>> >>>>>> xxxx >>>>>> >>>>>> The second also shortens by one step the XPath required >> to select >>>>>> this specific kind of element (and may reduce the size of an >>>>>> intermediate nodeset considerably). Of course, that also >> means it >>>>>> lengthens the XPath required to find all the XML elements >>>>>> corresponding to type "aaaa" in the underlying model... So >>>> as usual >>>>>> we are in a trade-off & need to judge which weighs heavier >>>> for our "market". >>>>>> Ann W. >>>>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >>> This e-mail is confidential and privileged. If you are not >> the intended recipient please accept our apologies; please do >> not disclose, copy or distribute information in this e-mail >> or take any action in reliance on its contents: to do so is >> strictly prohibited and may be unlawful. Please inform us >> that this message has gone astray before deleting it. Thank >> you for your co-operation. >>> >>> >> -- >> Grahame Grieve >> CTO, Jiva Medical Software Integration Tools >> CTO, Kestral Computing Healthcare Applications >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From GJEWELL at CERNER.COM Fri Jul 21 16:18:00 2006 From: GJEWELL at CERNER.COM (Jewell,Gaby) Date: Fri, 21 Jul 2006 10:18:00 -0500 Subject: [New-ITS] Compactness of style (was: RE: Element content vsattributes) Message-ID: <19FA77FD170347429EC43D7F4CDB198C035CBA37@MSMBWHQ10.northamerica.cerner.net> CWE also allows freetext, which is not allowed in the CFH messages. I had never heard this specific interpretation of CWE before. A SNOMED code is a SNOMED code. Unless I'm using code system version (which we're not in the CFH messages), how does someone know it's a "new" code? And if we are using code system version, why not just state which version of SNOMED the code came from? My understanding of extensions was more for HL7 or User-defined code systems, where the vocabulary can be extended in a local implementation. Gaby Jewell | Strategist | Cerner Corporation | office: 816.201.3290 | fax: 816.571.3290 | gjewell at cerner.com | www.cerner.com -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve Sent: Friday, July 21, 2006 7:59 AM To: Smithies Rik Cc: new-its at lists.hl7.org.uk Subject: Re: [New-ITS] Compactness of style (was: RE: Element content vsattributes) CWE says extensions are allowed. The most common case for extensions is when new codes are added for a new version of the codeSystem. CNE means they can't be adopted seamlessly whereas CWE says that they can. For this reason there is agreement at HL7 that snomed is always CWE. But I am not acquainted with CfH thinking on this issue, nor have I looked at the models to see how it's done. Grahame Smithies Rik wrote: > I may have missed the point, but I was expecting the codeSystem to be > only suppressible in cases of CNE. > > I realised that some models need to be generic and future proof, and > in those cases where any codeSystem can come along, you surely do need > to say the codeSystem. > > I'd like to think that serious used of CWE was rare though. Certainly > in CFH it isn't used much if at all. > > Is CWE meant for "send anything you like" or is it where multiple > codeSystem are sanctioned, but not all codeSystem, and you just cant > narrow it down to one for the diagram ? Or is that the point where > valueSets come into play ? What if you allow any code from 2 > codeSystem, is that CWE ? > > Rik > >> -----Original Message----- >> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame >> Grieve >> Sent: 21 July 2006 13:22 >> To: Smithies Rik >> Cc: Tim Benson; grahame at jivamedical.com; new-its at lists.hl7.org.uk; >> ann.wrightson at bt.com >> Subject: Re: [New-ITS] Compactness of style (was: RE: Element content >> vs attributes) >> >> that's right, the ruids are just token replacements for oids, so oids >> are still there in the background. >> >> I'm a little pessimistic that we can remove the codeSystem from the >> instance. The reason is the difference between valueSet and >> codeSystem - is there good machinery to infer that valueSet X with >> CWE means that the implementable model can regard the codeSystem as >> fixed? >> >> Grahame >> >> >> Smithies Rik wrote: >>> Hi Tim, Grahame >>> >>> >>>> Can we can do what we want without using OIDs? >>>> >>>> If OIDs did not already exist today, is there is a real user >>>> requirement to invent them? >>>> >>>> I think that the answers to the last 2 questions are >> probably YES and >>>> NO respectively >>> I would have suggested NO and YES, so what are the >> alternatives ? You >>> seem to need a namespacing method for codes and ids, hierarchical >>> ideally, to ease sub-allocation, so OIDs work pretty well >> imho. They >>> are verbose unfortunately. They also don't cover the requirement to >>> say what type of ID something is. >>> >>> UUIDs are also very verbose. You could certainly shrink >> messages a few >>> percent by using a more compressed UUID format (eg base 36). They >>> stick out like a sore thumb in flattened versions of current ITS >>> examples. I once looked for an alternative and nothing came up. >>> >>> I like the idea of RUIDs, which I have also never seen >> before. But if >>> in a given model a certain attribute is always, say, SCT, >> then there >>> is no theoretical need to send the codeSystem all, hence no great >>> advantage in shortening it. >>> >>> There is also the CodeSystemName if you want readability. >> The casual >>> reader of XML will just see it's a code and read the >> displayName. It >>> don't believe it help readability to the non-expert to have the OID >>> shown in "english" as an RUID, it would be best to just >> have code and >>> text. >>> >>> If the OID must be carried for some other reason, then if >> the RUID is >>> shorter so much the better, but two formats are harder to >> support than >>> one and OIDs aren't likely to disappear totally. >>> >>> Rik >>> >>>> -----Original Message----- >>>> From: new-its-bounces at lists.hl7.org.uk >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson >>>> Sent: 20 July 2006 12:49 >>>> To: grahame at jivamedical.com; ann.wrightson at bt.com >>>> Cc: new-its at lists.hl7.org.uk >>>> Subject: Re: [New-ITS] Compactness of style (was: RE: >> Element content >>>> vs attributes) >>>> >>>> The question is whether getting rid of OIDs would be >> friendly? This >>>> raises several related questions. >>>> >>>> Are people so familiar with oids that they would miss them? >>>> In teaching HL7 I have not met anyone who was familiar with OIDs >>>> outside of HL7. >>>> >>>> Can we can do what we want without using OIDs? >>>> >>>> If OIDs did not already exist today, is there is a real user >>>> requirement to invent them? >>>> >>>> I think that the answers to the last 2 questions are >> probably YES and >>>> NO respectively >>>> >>>> Tim >>>> >>>> On 20/7/06 10:27 Grahame Grieve wrote: >>>> >>>>> I will respond to this several times in different ways. >> One of the >>>>> things that this makes think is that we should dust off >>>> RUIDs. The HL7 >>>>> type UID is either UUID, OID, or RUID. We've never defined >>>> any RUIDs, >>>>> so no one really talks about them. But we (HL7) could - we could >>>>> define >>>>> >>>>> snomed-CT = [some long oid] >>>>> loinc = (some long oid) >>>>> [all HL7 codesets names] = (hl7 oids) other common candidates as >>>>> required >>>>> >>>>> then you could have >>>>> >>>>> (This doesn't address the xml issues - I Will take them up >>>>> separately.) >>>>> >>>>> But is this change something that would make the messages >>>> more friendly? >>>>> Actually, it's possible that the UK realm could just define these >>>>> without lengthy consultation with HL7 under realm >> localisation. The >>>>> comments in the abstract data types say: >>>>> >>>>> "A globally unique string defined exclusively by HL7. >>>> Identifiers in >>>>> this scheme are only defined by balloted HL7 >>>> specifications. Local >>>>> communities or systems must never use such reserved identifiers >>>>> based on bilateral negotiations" >>>>> >>>>> ambiguous where a realm sits here. We could seek >> clarification. But >>>>> this is only worthwhile if getting rid of the oids would be >>>> friendly. >>>>> comments? >>>>> >>>>> Grahame >>>>> >>>>> >>>>> ann.wrightson at bt.com wrote: >>>>>> A fork on the previous discussion: >>>>>> >>>>>> GG> I am left with a simple view: attributes are better >> cause they >>>>>> GG> use >>>>>> less space, so use them when you can. >>>>>> >>>>>> If you package a non-XML data structure into XML in two >>>> ways, first >>>>>> using a general rule of >>>> put-data-attributes-into-XML-attributes, then >>>>>> using a general rule of >>>> put-data-attributes-into-XML-child-elements, >>>>>> then yes XML attributes do use less space. >>>>>> >>>>>> However, if you allow translations that are more >> intelligent with >>>>>> respect to the nature of XML (for example, removing the >> constraint >>>>>> that all names and values in the abstractly-modelled >> non-XML data >>>>>> have to appear unchanged in the XML, including a short readable >>>>>> code-system-name in the implementable model, and thus >>>> allowing an OID >>>>>> to yield a readable tagname), an element-based style is >> able to be >>>>>> both readable and compact >>>>>> - and could still be generated from the non-XML model. Such >>>>>> intelligence does have some cost; I would justify that by >>>> saying it's >>>>>> for the same reason as terminologies don't just use >> code-numbers - >>>>>> people, developers no less than clinicians, need clear-text >>>>>> linguistic forms of reasonable reliability and not just >>>> formally-unambiguous gobbledegook. >>>>>> For example (from MIM 4.1.02): >>>>>> >>>>>> > code="371534008" >>>>>> displayName="summary report" /> >>>>>> >>>>>> can become: >>>>>> >>>>>> summary report >>>>>> >>>>>> without the total loss of signal in the XML regarding the >>>> terminology >>>>>> being used that happens if you instead go to this kind of >>>> style (MIM >>>>>> 4.1.03): >>>>>> >>>>>> >>>>>> >>>>>> The "loss of signal" for implementers has emerged as the main >>>>>> practical issue here, IMO. However, assuming that all the names >>>>>> involved are about the same length, there is also some >>>> difference in >>>>>> the right direction in overall length. At its simplest >> this is eg: >>>>>> >>>>>> >>>>>> becoming: >>>>>> >>>>>> xxxx >>>>>> >>>>>> The second also shortens by one step the XPath required >> to select >>>>>> this specific kind of element (and may reduce the size of an >>>>>> intermediate nodeset considerably). Of course, that also >> means it >>>>>> lengthens the XPath required to find all the XML elements >>>>>> corresponding to type "aaaa" in the underlying model... So >>>> as usual >>>>>> we are in a trade-off & need to judge which weighs heavier >>>> for our "market". >>>>>> Ann W. >>>>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >>> This e-mail is confidential and privileged. If you are not >> the intended recipient please accept our apologies; please do not >> disclose, copy or distribute information in this e-mail or take any >> action in reliance on its contents: to do so is strictly prohibited >> and may be unlawful. Please inform us that this message has gone >> astray before deleting it. Thank you for your co-operation. >>> >>> >> -- >> Grahame Grieve >> CTO, Jiva Medical Software Integration Tools >> CTO, Kestral Computing Healthcare Applications >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its ----------------------------------------- CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. ------------------------------------------- From rik.smithies at cfh.nhs.uk Fri Jul 21 16:40:56 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Fri, 21 Jul 2006 16:40:56 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vs attributes) Message-ID: <1A3D105C334EAE49BDDD93D8767573F50407BD01@EXCHAQ2.nhsia.nhs.uk> CFH has taken a different approach, perhaps wrongly then. I had assumed CNE was ok for SCT since anything in any version of "official" SCT is by definition in SCT OID-space. CFH models don't explicitly reference a particular release of SCT, and if they did it would need to keep changing. But if it said "CWE SnomedCT" I would have thought that meant you could send local codes, with different OIDs, which isnt what is intended. The Snomed OID is not tied to any version of SCT, so by saying OID+CNE, you are allowing anything covered by that OID, I would have thought, which includes future codes. Even if you say CWE, and take this to mean "allow new SCT codes", these still have the same OID, so you could still avoid sending it. If CWE allowed other coding systems (as I thought) then it would not be ok to miss out the OID. Subsets are used for when a fixed list of codes is wanted, and I'm not sure how versions of those subsets will be specified. But the OID would still always be the same I think. Rik > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 21 July 2006 13:59 > To: Smithies Rik > Cc: grahame at jivamedical.com; Tim Benson; > new-its at lists.hl7.org.uk; ann.wrightson at bt.com > Subject: Re: [New-ITS] Compactness of style (was: RE: Element > content vs attributes) > > CWE says extensions are allowed. The most common case for > extensions is when new codes are added for a new version of > the codeSystem. CNE means they can't be adopted seamlessly > whereas CWE says that they can. > > For this reason there is agreement at HL7 that snomed is > always CWE. But I am not acquainted with CfH thinking on this > issue, nor have I looked at the models to see how it's done. > > Grahame > > > Smithies Rik wrote: > > I may have missed the point, but I was expecting the > codeSystem to be > > only suppressible in cases of CNE. > > > > I realised that some models need to be generic and future > proof, and > > in those cases where any codeSystem can come along, you > surely do need > > to say the codeSystem. > > > > I'd like to think that serious used of CWE was rare though. > Certainly > > in CFH it isn't used much if at all. > > > > Is CWE meant for "send anything you like" or is it where multiple > > codeSystem are sanctioned, but not all codeSystem, and you > just cant > > narrow it down to one for the diagram ? Or is that the point where > > valueSets come into play ? What if you allow any code from 2 > > codeSystem, is that CWE ? > > > > Rik > > > >> -----Original Message----- > >> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf > Of Grahame > >> Grieve > >> Sent: 21 July 2006 13:22 > >> To: Smithies Rik > >> Cc: Tim Benson; grahame at jivamedical.com; new-its at lists.hl7.org.uk; > >> ann.wrightson at bt.com > >> Subject: Re: [New-ITS] Compactness of style (was: RE: > Element content > >> vs attributes) > >> > >> that's right, the ruids are just token replacements for > oids, so oids > >> are still there in the background. > >> > >> I'm a little pessimistic that we can remove the codeSystem > from the > >> instance. The reason is the difference between valueSet and > >> codeSystem - is there good machinery to infer that valueSet X with > >> CWE means that the implementable model can regard the > codeSystem as > >> fixed? > >> > >> Grahame > >> > >> > >> Smithies Rik wrote: > >>> Hi Tim, Grahame > >>> > >>> > >>>> Can we can do what we want without using OIDs? > >>>> > >>>> If OIDs did not already exist today, is there is a real user > >>>> requirement to invent them? > >>>> > >>>> I think that the answers to the last 2 questions are > >> probably YES and > >>>> NO respectively > >>> I would have suggested NO and YES, so what are the > >> alternatives ? You > >>> seem to need a namespacing method for codes and ids, hierarchical > >>> ideally, to ease sub-allocation, so OIDs work pretty well > >> imho. They > >>> are verbose unfortunately. They also don't cover the > requirement to > >>> say what type of ID something is. > >>> > >>> UUIDs are also very verbose. You could certainly shrink > >> messages a few > >>> percent by using a more compressed UUID format (eg base 36). They > >>> stick out like a sore thumb in flattened versions of current ITS > >>> examples. I once looked for an alternative and nothing came up. > >>> > >>> I like the idea of RUIDs, which I have also never seen > >> before. But if > >>> in a given model a certain attribute is always, say, SCT, > >> then there > >>> is no theoretical need to send the codeSystem all, hence no great > >>> advantage in shortening it. > >>> > >>> There is also the CodeSystemName if you want readability. > >> The casual > >>> reader of XML will just see it's a code and read the > >> displayName. It > >>> don't believe it help readability to the non-expert to > have the OID > >>> shown in "english" as an RUID, it would be best to just > >> have code and > >>> text. > >>> > >>> If the OID must be carried for some other reason, then if > >> the RUID is > >>> shorter so much the better, but two formats are harder to > >> support than > >>> one and OIDs aren't likely to disappear totally. > >>> > >>> Rik > >>> > >>>> -----Original Message----- > >>>> From: new-its-bounces at lists.hl7.org.uk > >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson > >>>> Sent: 20 July 2006 12:49 > >>>> To: grahame at jivamedical.com; ann.wrightson at bt.com > >>>> Cc: new-its at lists.hl7.org.uk > >>>> Subject: Re: [New-ITS] Compactness of style (was: RE: > >> Element content > >>>> vs attributes) > >>>> > >>>> The question is whether getting rid of OIDs would be > >> friendly? This > >>>> raises several related questions. > >>>> > >>>> Are people so familiar with oids that they would miss them? > >>>> In teaching HL7 I have not met anyone who was familiar with OIDs > >>>> outside of HL7. > >>>> > >>>> Can we can do what we want without using OIDs? > >>>> > >>>> If OIDs did not already exist today, is there is a real user > >>>> requirement to invent them? > >>>> > >>>> I think that the answers to the last 2 questions are > >> probably YES and > >>>> NO respectively > >>>> > >>>> Tim > >>>> > >>>> On 20/7/06 10:27 Grahame Grieve wrote: > >>>> > >>>>> I will respond to this several times in different ways. > >> One of the > >>>>> things that this makes think is that we should dust off > >>>> RUIDs. The HL7 > >>>>> type UID is either UUID, OID, or RUID. We've never defined > >>>> any RUIDs, > >>>>> so no one really talks about them. But we (HL7) could - > we could > >>>>> define > >>>>> > >>>>> snomed-CT = [some long oid] > >>>>> loinc = (some long oid) > >>>>> [all HL7 codesets names] = (hl7 oids) other common > candidates as > >>>>> required > >>>>> > >>>>> then you could have code="23123".../> > >>>>> > >>>>> (This doesn't address the xml issues - I Will take them up > >>>>> separately.) > >>>>> > >>>>> But is this change something that would make the messages > >>>> more friendly? > >>>>> Actually, it's possible that the UK realm could just > define these > >>>>> without lengthy consultation with HL7 under realm > >> localisation. The > >>>>> comments in the abstract data types say: > >>>>> > >>>>> "A globally unique string defined exclusively by HL7. > >>>> Identifiers in > >>>>> this scheme are only defined by balloted HL7 > >>>> specifications. Local > >>>>> communities or systems must never use such reserved > identifiers > >>>>> based on bilateral negotiations" > >>>>> > >>>>> ambiguous where a realm sits here. We could seek > >> clarification. But > >>>>> this is only worthwhile if getting rid of the oids would be > >>>> friendly. > >>>>> comments? > >>>>> > >>>>> Grahame > >>>>> > >>>>> > >>>>> ann.wrightson at bt.com wrote: > >>>>>> A fork on the previous discussion: > >>>>>> > >>>>>> GG> I am left with a simple view: attributes are better > >> cause they > >>>>>> GG> use > >>>>>> less space, so use them when you can. > >>>>>> > >>>>>> If you package a non-XML data structure into XML in two > >>>> ways, first > >>>>>> using a general rule of > >>>> put-data-attributes-into-XML-attributes, then > >>>>>> using a general rule of > >>>> put-data-attributes-into-XML-child-elements, > >>>>>> then yes XML attributes do use less space. > >>>>>> > >>>>>> However, if you allow translations that are more > >> intelligent with > >>>>>> respect to the nature of XML (for example, removing the > >> constraint > >>>>>> that all names and values in the abstractly-modelled > >> non-XML data > >>>>>> have to appear unchanged in the XML, including a short > readable > >>>>>> code-system-name in the implementable model, and thus > >>>> allowing an OID > >>>>>> to yield a readable tagname), an element-based style is > >> able to be > >>>>>> both readable and compact > >>>>>> - and could still be generated from the non-XML model. Such > >>>>>> intelligence does have some cost; I would justify that by > >>>> saying it's > >>>>>> for the same reason as terminologies don't just use > >> code-numbers - > >>>>>> people, developers no less than clinicians, need clear-text > >>>>>> linguistic forms of reasonable reliability and not just > >>>> formally-unambiguous gobbledegook. > >>>>>> For example (from MIM 4.1.02): > >>>>>> > >>>>>> >> code="371534008" > >>>>>> displayName="summary report" /> > >>>>>> > >>>>>> can become: > >>>>>> > >>>>>> summary report > >>>>>> > >>>>>> without the total loss of signal in the XML regarding the > >>>> terminology > >>>>>> being used that happens if you instead go to this kind of > >>>> style (MIM > >>>>>> 4.1.03): > >>>>>> > >>>>>> > >>>>>> > >>>>>> The "loss of signal" for implementers has emerged as the main > >>>>>> practical issue here, IMO. However, assuming that all > the names > >>>>>> involved are about the same length, there is also some > >>>> difference in > >>>>>> the right direction in overall length. At its simplest > >> this is eg: > >>>>>> > >>>>>> > >>>>>> becoming: > >>>>>> > >>>>>> xxxx > >>>>>> > >>>>>> The second also shortens by one step the XPath required > >> to select > >>>>>> this specific kind of element (and may reduce the size of an > >>>>>> intermediate nodeset considerably). Of course, that also > >> means it > >>>>>> lengthens the XPath required to find all the XML elements > >>>>>> corresponding to type "aaaa" in the underlying model... So > >>>> as usual > >>>>>> we are in a trade-off & need to judge which weighs heavier > >>>> for our "market". > >>>>>> Ann W. > >>>>>> > >>>> _______________________________________________ > >>>> New-ITS mailing list > >>>> New-ITS at lists.hl7.org.uk > >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its > >>>> > >>> This e-mail is confidential and privileged. If you are not > >> the intended recipient please accept our apologies; please do not > >> disclose, copy or distribute information in this e-mail or > take any > >> action in reliance on its contents: to do so is strictly > prohibited > >> and may be unlawful. Please inform us that this message has gone > >> astray before deleting it. Thank you for your co-operation. > >>> > >>> > >> -- > >> Grahame Grieve > >> CTO, Jiva Medical Software Integration Tools > >> CTO, Kestral Computing Healthcare Applications > >> > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > From rik.smithies at cfh.nhs.uk Fri Jul 21 16:47:46 2006 From: rik.smithies at cfh.nhs.uk (Smithies Rik) Date: Fri, 21 Jul 2006 16:47:46 +0100 Subject: [New-ITS] Compactness of style (was: RE: Element content vsattributes) Message-ID: <1A3D105C334EAE49BDDD93D8767573F50407BD0B@EXCHAQ2.nhsia.nhs.uk> Gaby, I should have read your post before I sent mine because you say just what I meant ;-) Rik > -----Original Message----- > From: Jewell,Gaby [mailto:GJEWELL at CERNER.COM] > Sent: 21 July 2006 16:18 > To: grahame at jivamedical.com; Smithies Rik > Cc: new-its at lists.hl7.org.uk > Subject: RE: [New-ITS] Compactness of style (was: RE: Element > content vsattributes) > > CWE also allows freetext, which is not allowed in the CFH messages. > > I had never heard this specific interpretation of CWE before. > A SNOMED code is a SNOMED code. Unless I'm using code > system version (which we're not in the CFH messages), how > does someone know it's a "new" code? > And if we are using code system version, why not just state > which version of SNOMED the code came from? > > My understanding of extensions was more for HL7 or > User-defined code systems, where the vocabulary can be > extended in a local implementation. > > > > Gaby Jewell | Strategist | Cerner Corporation | office: 816.201.3290 | > fax: 816.571.3290 | gjewell at cerner.com | www.cerner.com > > > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: Friday, July 21, 2006 7:59 AM > To: Smithies Rik > Cc: new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] Compactness of style (was: RE: Element content > vsattributes) > > CWE says extensions are allowed. The most common case for > extensions is when new codes are added for a new version of > the codeSystem. CNE means they can't be adopted seamlessly > whereas CWE says that they can. > > For this reason there is agreement at HL7 that snomed is > always CWE. But I am not acquainted with CfH thinking on this > issue, nor have I looked at the models to see how it's done. > > Grahame > > > Smithies Rik wrote: > > I may have missed the point, but I was expecting the > codeSystem to be > > only suppressible in cases of CNE. > > > > I realised that some models need to be generic and future > proof, and > > in those cases where any codeSystem can come along, you > surely do need > > > to say the codeSystem. > > > > I'd like to think that serious used of CWE was rare though. > Certainly > > in CFH it isn't used much if at all. > > > > Is CWE meant for "send anything you like" or is it where multiple > > codeSystem are sanctioned, but not all codeSystem, and you > just cant > > narrow it down to one for the diagram ? Or is that the point where > > valueSets come into play ? What if you allow any code from 2 > > codeSystem, is that CWE ? > > > > Rik > > > >> -----Original Message----- > >> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf > Of Grahame > > >> Grieve > >> Sent: 21 July 2006 13:22 > >> To: Smithies Rik > >> Cc: Tim Benson; grahame at jivamedical.com; new-its at lists.hl7.org.uk; > >> ann.wrightson at bt.com > >> Subject: Re: [New-ITS] Compactness of style (was: RE: > Element content > > >> vs attributes) > >> > >> that's right, the ruids are just token replacements for > oids, so oids > > >> are still there in the background. > >> > >> I'm a little pessimistic that we can remove the codeSystem > from the > >> instance. The reason is the difference between valueSet and > >> codeSystem - is there good machinery to infer that valueSet X with > >> CWE means that the implementable model can regard the > codeSystem as > >> fixed? > >> > >> Grahame > >> > >> > >> Smithies Rik wrote: > >>> Hi Tim, Grahame > >>> > >>> > >>>> Can we can do what we want without using OIDs? > >>>> > >>>> If OIDs did not already exist today, is there is a real user > >>>> requirement to invent them? > >>>> > >>>> I think that the answers to the last 2 questions are > >> probably YES and > >>>> NO respectively > >>> I would have suggested NO and YES, so what are the > >> alternatives ? You > >>> seem to need a namespacing method for codes and ids, hierarchical > >>> ideally, to ease sub-allocation, so OIDs work pretty well > >> imho. They > >>> are verbose unfortunately. They also don't cover the > requirement to > >>> say what type of ID something is. > >>> > >>> UUIDs are also very verbose. You could certainly shrink > >> messages a few > >>> percent by using a more compressed UUID format (eg base 36). They > >>> stick out like a sore thumb in flattened versions of current ITS > >>> examples. I once looked for an alternative and nothing came up. > >>> > >>> I like the idea of RUIDs, which I have also never seen > >> before. But if > >>> in a given model a certain attribute is always, say, SCT, > >> then there > >>> is no theoretical need to send the codeSystem all, hence no great > >>> advantage in shortening it. > >>> > >>> There is also the CodeSystemName if you want readability. > >> The casual > >>> reader of XML will just see it's a code and read the > >> displayName. It > >>> don't believe it help readability to the non-expert to > have the OID > >>> shown in "english" as an RUID, it would be best to just > >> have code and > >>> text. > >>> > >>> If the OID must be carried for some other reason, then if > >> the RUID is > >>> shorter so much the better, but two formats are harder to > >> support than > >>> one and OIDs aren't likely to disappear totally. > >>> > >>> Rik > >>> > >>>> -----Original Message----- > >>>> From: new-its-bounces at lists.hl7.org.uk > >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson > >>>> Sent: 20 July 2006 12:49 > >>>> To: grahame at jivamedical.com; ann.wrightson at bt.com > >>>> Cc: new-its at lists.hl7.org.uk > >>>> Subject: Re: [New-ITS] Compactness of style (was: RE: > >> Element content > >>>> vs attributes) > >>>> > >>>> The question is whether getting rid of OIDs would be > >> friendly? This > >>>> raises several related questions. > >>>> > >>>> Are people so familiar with oids that they would miss them? > >>>> In teaching HL7 I have not met anyone who was familiar with OIDs > >>>> outside of HL7. > >>>> > >>>> Can we can do what we want without using OIDs? > >>>> > >>>> If OIDs did not already exist today, is there is a real user > >>>> requirement to invent them? > >>>> > >>>> I think that the answers to the last 2 questions are > >> probably YES and > >>>> NO respectively > >>>> > >>>> Tim > >>>> > >>>> On 20/7/06 10:27 Grahame Grieve wrote: > >>>> > >>>>> I will respond to this several times in different ways. > >> One of the > >>>>> things that this makes think is that we should dust off > >>>> RUIDs. The HL7 > >>>>> type UID is either UUID, OID, or RUID. We've never defined > >>>> any RUIDs, > >>>>> so no one really talks about them. But we (HL7) could - > we could > >>>>> define > >>>>> > >>>>> snomed-CT = [some long oid] > >>>>> loinc = (some long oid) > >>>>> [all HL7 codesets names] = (hl7 oids) other common > candidates as > >>>>> required > >>>>> > >>>>> then you could have code="23123".../> > >>>>> > >>>>> (This doesn't address the xml issues - I Will take them up > >>>>> separately.) > >>>>> > >>>>> But is this change something that would make the messages > >>>> more friendly? > >>>>> Actually, it's possible that the UK realm could just > define these > >>>>> without lengthy consultation with HL7 under realm > >> localisation. The > >>>>> comments in the abstract data types say: > >>>>> > >>>>> "A globally unique string defined exclusively by HL7. > >>>> Identifiers in > >>>>> this scheme are only defined by balloted HL7 > >>>> specifications. Local > >>>>> communities or systems must never use such reserved > identifiers > >>>>> based on bilateral negotiations" > >>>>> > >>>>> ambiguous where a realm sits here. We could seek > >> clarification. But > >>>>> this is only worthwhile if getting rid of the oids would be > >>>> friendly. > >>>>> comments? > >>>>> > >>>>> Grahame > >>>>> > >>>>> > >>>>> ann.wrightson at bt.com wrote: > >>>>>> A fork on the previous discussion: > >>>>>> > >>>>>> GG> I am left with a simple view: attributes are better > >> cause they > >>>>>> GG> use > >>>>>> less space, so use them when you can. > >>>>>> > >>>>>> If you package a non-XML data structure into XML in two > >>>> ways, first > >>>>>> using a general rule of > >>>> put-data-attributes-into-XML-attributes, then > >>>>>> using a general rule of > >>>> put-data-attributes-into-XML-child-elements, > >>>>>> then yes XML attributes do use less space. > >>>>>> > >>>>>> However, if you allow translations that are more > >> intelligent with > >>>>>> respect to the nature of XML (for example, removing the > >> constraint > >>>>>> that all names and values in the abstractly-modelled > >> non-XML data > >>>>>> have to appear unchanged in the XML, including a short > readable > >>>>>> code-system-name in the implementable model, and thus > >>>> allowing an OID > >>>>>> to yield a readable tagname), an element-based style is > >> able to be > >>>>>> both readable and compact > >>>>>> - and could still be generated from the non-XML model. Such > >>>>>> intelligence does have some cost; I would justify that by > >>>> saying it's > >>>>>> for the same reason as terminologies don't just use > >> code-numbers - > >>>>>> people, developers no less than clinicians, need clear-text > >>>>>> linguistic forms of reasonable reliability and not just > >>>> formally-unambiguous gobbledegook. > >>>>>> For example (from MIM 4.1.02): > >>>>>> > >>>>>> >> code="371534008" > >>>>>> displayName="summary report" /> > >>>>>> > >>>>>> can become: > >>>>>> > >>>>>> summary report > >>>>>> > >>>>>> without the total loss of signal in the XML regarding the > >>>> terminology > >>>>>> being used that happens if you instead go to this kind of > >>>> style (MIM > >>>>>> 4.1.03): > >>>>>> > >>>>>> > >>>>>> > >>>>>> The "loss of signal" for implementers has emerged as the main > >>>>>> practical issue here, IMO. However, assuming that all > the names > >>>>>> involved are about the same length, there is also some > >>>> difference in > >>>>>> the right direction in overall length. At its simplest > >> this is eg: > >>>>>> > >>>>>> > >>>>>> becoming: > >>>>>> > >>>>>> xxxx > >>>>>> > >>>>>> The second also shortens by one step the XPath required > >> to select > >>>>>> this specific kind of element (and may reduce the size of an > >>>>>> intermediate nodeset considerably). Of course, that also > >> means it > >>>>>> lengthens the XPath required to find all the XML elements > >>>>>> corresponding to type "aaaa" in the underlying model... So > >>>> as usual > >>>>>> we are in a trade-off & need to judge which weighs heavier > >>>> for our "market". > >>>>>> Ann W. > >>>>>> > >>>> _______________________________________________ > >>>> New-ITS mailing list > >>>> New-ITS at lists.hl7.org.uk > >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its > >>>> > >>> This e-mail is confidential and privileged. If you are not > >> the intended recipient please accept our apologies; please do not > >> disclose, copy or distribute information in this e-mail or > take any > >> action in reliance on its contents: to do so is strictly > prohibited > >> and may be unlawful. Please inform us that this message has gone > >> astray before deleting it. Thank you for your co-operation. > >>> > >>> > >> -- > >> Grahame Grieve > >> CTO, Jiva Medical Software Integration Tools > >> CTO, Kestral Computing Healthcare Applications > >> > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > ----------------------------------------- > CONFIDENTIALITY NOTICE This message and any included > attachments are from Cerner Corporation and are intended only > for the addressee. The information contained in this message > is confidential and may constitute inside or non-public > information under international, federal, or state securities laws. > Unauthorized forwarding, printing, copying, distribution, or > use of such information is strictly prohibited and may be > unlawful. If you are not the addressee, please promptly > delete this message and notify the sender of the delivery > error by e-mail or you may call Cerner's corporate offices in > Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > ------------------------------------------- > > From Thomas.Beale at OceanInformatics.biz Fri Jul 21 17:46:17 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 21 Jul 2006 17:46:17 +0100 Subject: [New-ITS] XML design principles In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1F69C@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1F69C@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44C104D9.5020002@OceanInformatics.biz> An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060721/86a3f660/attachment-0001.htm From Thomas.Beale at OceanInformatics.biz Fri Jul 21 18:06:50 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 21 Jul 2006 18:06:50 +0100 Subject: [New-ITS] Element content vs attributes In-Reply-To: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> References: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> Message-ID: <44C109AA.2040501@OceanInformatics.biz> ann.wrightson at bt.com wrote: > Here is a reference on this rather fundamental matter: > http://xml.coverpages.org/elementsAndAttrs.html > This is the classic aesthetic battle I mentioned earlier. The only mapping that make sense is one that is: a) consistent throughout the model b) and therefore automatable. In my view, the only sensible is that all attributes and relations from a UML model become elements in XML; the only exceptions are things that are really intended as meta-data, such as certain identifiers (often found in specially named UML attributes). This means that even String and Integer properties are Elements; that's they way it should be - everything is an object; these leaf values are not meta-data (not generally anyway). When we were arguing about this in the GeHR work in Australia, for building an XML archetype processor, the developers got stuck in the classic aesthetics debate and decided on the basis of what looked nice (I am always amazed to think that anyone would waste 1 minute on this kind of thinking); finally when they tried to build the software they made everything an Element. You will see this is what we do in openEHR as well; everything works properly if you do it ; e.g. see http://svn.openehr.org/specification/TRUNK/publishing/its/XML-schema/documentation/Content.xsd.html_h-65908089.html ; see here for use of XML attributes - http://svn.openehr.org/specification/TRUNK/publishing/its/XML-schema/documentation/Structure.xsd.html_h911858792.html When you start designing path-based processing, the correct approach immediately becomes clearer. - thomas beale From Thomas.Beale at OceanInformatics.biz Fri Jul 21 18:09:50 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 21 Jul 2006 18:09:50 +0100 Subject: [New-ITS] Element content vs attributes In-Reply-To: <44BE2409.9090001@kestral.com.au> References: <849288029444F74899F8C8E3D479FF6DA1FB4F@E03MVZ3-UKDY.domain1.systemhost.net> <44BE2409.9090001@kestral.com.au> Message-ID: <44C10A5E.9030405@OceanInformatics.biz> Grahame Grieve wrote: > I am left with a simple view: attributes are better cause > they use less space, so use them when you can. > unfortunately this ad hoc approach doesn't work well in practice - it prevents systematic software processing; it particularly makes the creation, processing of path-based queries difficult, since you don't know easily if you will use the attribute-based predicate formulation xxxxx[@aaaa=123] or not. - thomas From Thomas.Beale at OceanInformatics.biz Fri Jul 21 18:13:38 2006 From: Thomas.Beale at OceanInformatics.biz (Thomas Beale) Date: Fri, 21 Jul 2006 18:13:38 +0100 Subject: [New-ITS] Element content vs attributes In-Reply-To: <44BE2FD3.9090601@kestral.com.au> References: <849288029444F74899F8C8E3D479FF6DA83C7C@E03MVZ3-UKDY.domain1.systemhost.net> <44BE2FD3.9090601@kestral.com.au> Message-ID: <44C10B42.6030700@OceanInformatics.biz> Grahame Grieve wrote: > if only xml had introduced as a shorthand for close the > current element.... > hence the reason we don't use it internally in openEHR or archetypes - see the dADL syntax definition in Section 3 of http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html; half the size of XML, properly object-oriented, handles containers and nested containers properly, and is X-path compatible. Plus you can read it. - thomas beale -- ___________________________________________________________________________________ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) From grahame at kestral.com.au Sat Jul 22 01:13:24 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Sat, 22 Jul 2006 10:13:24 +1000 Subject: [New-ITS] Compactness of style (was: RE: Element content vsattributes) In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F50407BD0B@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F50407BD0B@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44C16DA4.5050600@kestral.com.au> hmm. maybe I misunderstood what the intention was in the discussion that agreed that CWE was right for snomed. I'll clarify Grahame Smithies Rik wrote: > Gaby, > I should have read your post before I sent mine because you say just > what I meant ;-) > Rik > >> -----Original Message----- >> From: Jewell,Gaby [mailto:GJEWELL at CERNER.COM] >> Sent: 21 July 2006 16:18 >> To: grahame at jivamedical.com; Smithies Rik >> Cc: new-its at lists.hl7.org.uk >> Subject: RE: [New-ITS] Compactness of style (was: RE: Element >> content vsattributes) >> >> CWE also allows freetext, which is not allowed in the CFH messages. >> >> I had never heard this specific interpretation of CWE before. >> A SNOMED code is a SNOMED code. Unless I'm using code >> system version (which we're not in the CFH messages), how >> does someone know it's a "new" code? >> And if we are using code system version, why not just state >> which version of SNOMED the code came from? >> >> My understanding of extensions was more for HL7 or >> User-defined code systems, where the vocabulary can be >> extended in a local implementation. >> >> >> >> Gaby Jewell | Strategist | Cerner Corporation | office: 816.201.3290 | >> fax: 816.571.3290 | gjewell at cerner.com | www.cerner.com >> >> >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve >> Sent: Friday, July 21, 2006 7:59 AM >> To: Smithies Rik >> Cc: new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] Compactness of style (was: RE: Element content >> vsattributes) >> >> CWE says extensions are allowed. The most common case for >> extensions is when new codes are added for a new version of >> the codeSystem. CNE means they can't be adopted seamlessly >> whereas CWE says that they can. >> >> For this reason there is agreement at HL7 that snomed is >> always CWE. But I am not acquainted with CfH thinking on this >> issue, nor have I looked at the models to see how it's done. >> >> Grahame >> >> >> Smithies Rik wrote: >>> I may have missed the point, but I was expecting the >> codeSystem to be >>> only suppressible in cases of CNE. >>> >>> I realised that some models need to be generic and future >> proof, and >>> in those cases where any codeSystem can come along, you >> surely do need >> >>> to say the codeSystem. >>> >>> I'd like to think that serious used of CWE was rare though. >> Certainly >>> in CFH it isn't used much if at all. >>> >>> Is CWE meant for "send anything you like" or is it where multiple >>> codeSystem are sanctioned, but not all codeSystem, and you >> just cant >>> narrow it down to one for the diagram ? Or is that the point where >>> valueSets come into play ? What if you allow any code from 2 >>> codeSystem, is that CWE ? >>> >>> Rik >>> >>>> -----Original Message----- >>>> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf >> Of Grahame >> >>>> Grieve >>>> Sent: 21 July 2006 13:22 >>>> To: Smithies Rik >>>> Cc: Tim Benson; grahame at jivamedical.com; new-its at lists.hl7.org.uk; >>>> ann.wrightson at bt.com >>>> Subject: Re: [New-ITS] Compactness of style (was: RE: >> Element content >> >>>> vs attributes) >>>> >>>> that's right, the ruids are just token replacements for >> oids, so oids >> >>>> are still there in the background. >>>> >>>> I'm a little pessimistic that we can remove the codeSystem >> from the >>>> instance. The reason is the difference between valueSet and >>>> codeSystem - is there good machinery to infer that valueSet X with >>>> CWE means that the implementable model can regard the >> codeSystem as >>>> fixed? >>>> >>>> Grahame >>>> >>>> >>>> Smithies Rik wrote: >>>>> Hi Tim, Grahame >>>>> >>>>> >>>>>> Can we can do what we want without using OIDs? >>>>>> >>>>>> If OIDs did not already exist today, is there is a real user >>>>>> requirement to invent them? >>>>>> >>>>>> I think that the answers to the last 2 questions are >>>> probably YES and >>>>>> NO respectively >>>>> I would have suggested NO and YES, so what are the >>>> alternatives ? You >>>>> seem to need a namespacing method for codes and ids, hierarchical >>>>> ideally, to ease sub-allocation, so OIDs work pretty well >>>> imho. They >>>>> are verbose unfortunately. They also don't cover the >> requirement to >>>>> say what type of ID something is. >>>>> >>>>> UUIDs are also very verbose. You could certainly shrink >>>> messages a few >>>>> percent by using a more compressed UUID format (eg base 36). They >>>>> stick out like a sore thumb in flattened versions of current ITS >>>>> examples. I once looked for an alternative and nothing came up. >>>>> >>>>> I like the idea of RUIDs, which I have also never seen >>>> before. But if >>>>> in a given model a certain attribute is always, say, SCT, >>>> then there >>>>> is no theoretical need to send the codeSystem all, hence no great >>>>> advantage in shortening it. >>>>> >>>>> There is also the CodeSystemName if you want readability. >>>> The casual >>>>> reader of XML will just see it's a code and read the >>>> displayName. It >>>>> don't believe it help readability to the non-expert to >> have the OID >>>>> shown in "english" as an RUID, it would be best to just >>>> have code and >>>>> text. >>>>> >>>>> If the OID must be carried for some other reason, then if >>>> the RUID is >>>>> shorter so much the better, but two formats are harder to >>>> support than >>>>> one and OIDs aren't likely to disappear totally. >>>>> >>>>> Rik >>>>> >>>>>> -----Original Message----- >>>>>> From: new-its-bounces at lists.hl7.org.uk >>>>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Tim Benson >>>>>> Sent: 20 July 2006 12:49 >>>>>> To: grahame at jivamedical.com; ann.wrightson at bt.com >>>>>> Cc: new-its at lists.hl7.org.uk >>>>>> Subject: Re: [New-ITS] Compactness of style (was: RE: >>>> Element content >>>>>> vs attributes) >>>>>> >>>>>> The question is whether getting rid of OIDs would be >>>> friendly? This >>>>>> raises several related questions. >>>>>> >>>>>> Are people so familiar with oids that they would miss them? >>>>>> In teaching HL7 I have not met anyone who was familiar with OIDs >>>>>> outside of HL7. >>>>>> >>>>>> Can we can do what we want without using OIDs? >>>>>> >>>>>> If OIDs did not already exist today, is there is a real user >>>>>> requirement to invent them? >>>>>> >>>>>> I think that the answers to the last 2 questions are >>>> probably YES and >>>>>> NO respectively >>>>>> >>>>>> Tim >>>>>> >>>>>> On 20/7/06 10:27 Grahame Grieve wrote: >>>>>> >>>>>>> I will respond to this several times in different ways. >>>> One of the >>>>>>> things that this makes think is that we should dust off >>>>>> RUIDs. The HL7 >>>>>>> type UID is either UUID, OID, or RUID. We've never defined >>>>>> any RUIDs, >>>>>>> so no one really talks about them. But we (HL7) could - >> we could >>>>>>> define >>>>>>> >>>>>>> snomed-CT = [some long oid] >>>>>>> loinc = (some long oid) >>>>>>> [all HL7 codesets names] = (hl7 oids) other common >> candidates as >>>>>>> required >>>>>>> >>>>>>> then you could have > code="23123".../> >>>>>>> (This doesn't address the xml issues - I Will take them up >>>>>>> separately.) >>>>>>> >>>>>>> But is this change something that would make the messages >>>>>> more friendly? >>>>>>> Actually, it's possible that the UK realm could just >> define these >>>>>>> without lengthy consultation with HL7 under realm >>>> localisation. The >>>>>>> comments in the abstract data types say: >>>>>>> >>>>>>> "A globally unique string defined exclusively by HL7. >>>>>> Identifiers in >>>>>>> this scheme are only defined by balloted HL7 >>>>>> specifications. Local >>>>>>> communities or systems must never use such reserved >> identifiers >>>>>>> based on bilateral negotiations" >>>>>>> >>>>>>> ambiguous where a realm sits here. We could seek >>>> clarification. But >>>>>>> this is only worthwhile if getting rid of the oids would be >>>>>> friendly. >>>>>>> comments? >>>>>>> >>>>>>> Grahame >>>>>>> >>>>>>> >>>>>>> ann.wrightson at bt.com wrote: >>>>>>>> A fork on the previous discussion: >>>>>>>> >>>>>>>> GG> I am left with a simple view: attributes are better >>>> cause they >>>>>>>> GG> use >>>>>>>> less space, so use them when you can. >>>>>>>> >>>>>>>> If you package a non-XML data structure into XML in two >>>>>> ways, first >>>>>>>> using a general rule of >>>>>> put-data-attributes-into-XML-attributes, then >>>>>>>> using a general rule of >>>>>> put-data-attributes-into-XML-child-elements, >>>>>>>> then yes XML attributes do use less space. >>>>>>>> >>>>>>>> However, if you allow translations that are more >>>> intelligent with >>>>>>>> respect to the nature of XML (for example, removing the >>>> constraint >>>>>>>> that all names and values in the abstractly-modelled >>>> non-XML data >>>>>>>> have to appear unchanged in the XML, including a short >> readable >>>>>>>> code-system-name in the implementable model, and thus >>>>>> allowing an OID >>>>>>>> to yield a readable tagname), an element-based style is >>>> able to be >>>>>>>> both readable and compact >>>>>>>> - and could still be generated from the non-XML model. Such >>>>>>>> intelligence does have some cost; I would justify that by >>>>>> saying it's >>>>>>>> for the same reason as terminologies don't just use >>>> code-numbers - >>>>>>>> people, developers no less than clinicians, need clear-text >>>>>>>> linguistic forms of reasonable reliability and not just >>>>>> formally-unambiguous gobbledegook. >>>>>>>> For example (from MIM 4.1.02): >>>>>>>> >>>>>>>> >>> code="371534008" >>>>>>>> displayName="summary report" /> >>>>>>>> >>>>>>>> can become: >>>>>>>> >>>>>>>> summary report >>>>>>>> >>>>>>>> without the total loss of signal in the XML regarding the >>>>>> terminology >>>>>>>> being used that happens if you instead go to this kind of >>>>>> style (MIM >>>>>>>> 4.1.03): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The "loss of signal" for implementers has emerged as the main >>>>>>>> practical issue here, IMO. However, assuming that all >> the names >>>>>>>> involved are about the same length, there is also some >>>>>> difference in >>>>>>>> the right direction in overall length. At its simplest >>>> this is eg: >>>>>>>> >>>>>>>> >>>>>>>> becoming: >>>>>>>> >>>>>>>> xxxx >>>>>>>> >>>>>>>> The second also shortens by one step the XPath required >>>> to select >>>>>>>> this specific kind of element (and may reduce the size of an >>>>>>>> intermediate nodeset considerably). Of course, that also >>>> means it >>>>>>>> lengthens the XPath required to find all the XML elements >>>>>>>> corresponding to type "aaaa" in the underlying model... So >>>>>> as usual >>>>>>>> we are in a trade-off & need to judge which weighs heavier >>>>>> for our "market". >>>>>>>> Ann W. >>>>>>>> >>>>>> _______________________________________________ >>>>>> New-ITS mailing list >>>>>> New-ITS at lists.hl7.org.uk >>>>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>>>> >>>>> This e-mail is confidential and privileged. If you are not >>>> the intended recipient please accept our apologies; please do not >>>> disclose, copy or distribute information in this e-mail or >> take any >>>> action in reliance on its contents: to do so is strictly >> prohibited >>>> and may be unlawful. Please inform us that this message has gone >>>> astray before deleting it. Thank you for your co-operation. >>>>> >>>> -- >>>> Grahame Grieve >>>> CTO, Jiva Medical Software Integration Tools >>>> CTO, Kestral Computing Healthcare Applications >>>> >> -- >> Grahame Grieve >> CTO, Jiva Medical Software Integration Tools >> CTO, Kestral Computing Healthcare Applications >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> >> ----------------------------------------- >> CONFIDENTIALITY NOTICE This message and any included >> attachments are from Cerner Corporation and are intended only >> for the addressee. The information contained in this message >> is confidential and may constitute inside or non-public >> information under international, federal, or state securities laws. >> Unauthorized forwarding, printing, copying, distribution, or >> use of such information is strictly prohibited and may be >> unlawful. If you are not the addressee, please promptly >> delete this message and notify the sender of the delivery >> error by e-mail or you may call Cerner's corporate offices in >> Kansas City, Missouri, U.S.A at (+1) (816)221-1024. >> ------------------------------------------- >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Sat Jul 22 01:32:56 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Sat, 22 Jul 2006 10:32:56 +1000 Subject: [New-ITS] Wiki Message-ID: <44C17238.6050304@kestral.com.au> There is a wiki for the new ITS. content is gradually building on the wiki. http://b2international.com/umlits/index.php/Main_Page The wiki requires a user name and password username: wiki password: wikiwiki grants read-only access. This username and password can be distributed. Grahame From tim.benson at abies.co.uk Sat Jul 22 09:25:16 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Sat, 22 Jul 2006 09:25:16 +0100 Subject: [New-ITS] HL7 and MDA Message-ID: Graham, I am responding to your piece on the wiki about MDA. One of the myths in the HL7 methodology is that there is rough correspondence between MDA and HL7 HDF. This myth originates from linking the original work in CEN TC251, which developed the idea of syntax-independent standard message specifications (General Message Descriptions) that could be implemented in various different syntaxes, with the MDA paradigm. The conventional view is: CIM => DAM PIM => RMIM PSM => ITS The MDA is a useful framework, but it was designed for writing software applications not for messaging. My understanding is: CIM describes the high-level business processes of the proposed system and is typically documented using use case descriptions and activity diagrams. Class models in CIMs are sketches and not prescriptive. The purpose is to define the scope and all of the business processes that are to be supported. PIM is a stringent specification of the logical design of the system, covering all details that are of interest to the user or domain expert at each end. This must be understood by, reviewed by and approved by the domain experts as well as by the technology experts. It is the basis of the contract between users at each end, their software developers and the integration engineers. PSM is the precise specification of what is to be built. It is technology specific and only needs to be understood by technology experts (integration engineers and software developers at each end). It is now accepted that "the domain expert in the street" (to use Charlie Mead's term) cannot safely understand RMIMs and other RIM-based artefacts. The consequence of this key fact is that these artefacts should be regarded as PSM, not PIM artefacts. RIM-based artefacts are PSM artefacts used by technology experts and should not be used in reviewing message designs with domain experts. We need to put much more work into developing genuine PIMs, which may be referred to as DAM Profiles. A DAM Profile is a precise logical design specification of a single message to do a single job. It makes sense, for reasons I will not go into here, to develop DAM Profiles as specific views into a larger model - the DAM. If these arguments are accepted, the relationship between MDA and HL7 should read: CIM => Scope and Business Process Model PIM => DAM or DAM Profile(s) PSM => RMIM and ITS Best wishes Tim From grahame at kestral.com.au Sat Jul 22 11:55:54 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Sat, 22 Jul 2006 20:55:54 +1000 Subject: [New-ITS] HL7 and MDA In-Reply-To: References: Message-ID: <44C2043A.4070703@kestral.com.au> hi Tim I can follow your argument. I'm not sure that I agree though. I guess that the question is whether the fact that RMIMs are not understandable to the domain expert in the street means that they are PSMs, or whether it means they are failed PIMs. I don't think that any technologist would understand them as a useful technology specification either. All PIMS are also PSMs, but the platform the are specific for has mappings to other platforms, usually useful platforms for implementation. But I can see the logic that the DAM is closer to a PIM too. I guess this shows that a) HL7 is a standards developer, not an application developer b) we don't do what we are doing very well c) there is a loose correlation between the system design approach - like between MDA, RM-ODP, TOGAF, etc Grahame Tim Benson wrote: > Graham, > > I am responding to your piece on the wiki about MDA. > > One of the myths in the HL7 methodology is that there is rough > correspondence between MDA and HL7 HDF. This myth originates from linking > the original work in CEN TC251, which developed the idea of > syntax-independent standard message specifications (General Message > Descriptions) that could be implemented in various different syntaxes, with > the MDA paradigm. > > The conventional view is: > > CIM => DAM > PIM => RMIM > PSM => ITS > > The MDA is a useful framework, but it was designed for writing software > applications not for messaging. My understanding is: > > CIM describes the high-level business processes of the proposed system and > is typically documented using use case descriptions and activity diagrams. > Class models in CIMs are sketches and not prescriptive. The purpose is to > define the scope and all of the business processes that are to be supported. > > PIM is a stringent specification of the logical design of the system, > covering all details that are of interest to the user or domain expert at > each end. This must be understood by, reviewed by and approved by the > domain experts as well as by the technology experts. It is the basis of the > contract between users at each end, their software developers and the > integration engineers. > > PSM is the precise specification of what is to be built. It is technology > specific and only needs to be understood by technology experts (integration > engineers and software developers at each end). > > It is now accepted that "the domain expert in the street" (to use Charlie > Mead's term) cannot safely understand RMIMs and other RIM-based artefacts. > The consequence of this key fact is that these artefacts should be regarded > as PSM, not PIM artefacts. > > RIM-based artefacts are PSM artefacts used by technology experts and should > not be used in reviewing message designs with domain experts. We need to > put much more work into developing genuine PIMs, which may be referred to as > DAM Profiles. > > A DAM Profile is a precise logical design specification of a single message > to do a single job. It makes sense, for reasons I will not go into here, to > develop DAM Profiles as specific views into a larger model - the DAM. > > If these arguments are accepted, the relationship between MDA and HL7 should > read: > > CIM => Scope and Business Process Model > PIM => DAM or DAM Profile(s) > PSM => RMIM and ITS > > Best wishes > > Tim > > > > > > > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Sat Jul 22 14:22:56 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Sat, 22 Jul 2006 14:22:56 +0100 Subject: [New-ITS] HL7 and MDA In-Reply-To: <44C2043A.4070703@kestral.com.au> Message-ID: Hi Grahame, Apologies for a verbose response, but I feel that this issue is right at the heart of our problems. In any design and build operation there are usually at least two specifications. The useful distinction is what a specification is used for, not whether it is or is not specific to a particular platform or technology. I recognise two fundamental uses for specifications (blueprints). The first is between the customer and the service provider, which specifies clearly what the customer will get. This is the basis of the contract between them. This specification is the exact equivalent of the PIM or DAM Profile. The second type of specification, which is only used in manufacture, is the exact equivalent of the PSM. This is the technical specification which is used in the actual build. An analogy is the purchase of a new kitchen. The kitchen designer prepares a detailed plan of the new kitchen. This plan is checked, reviewed and signed off by the customer and is the basis of the contract. All of the details that are important to the user (sizes, colour etc.) are specified precisely and agreed with the customer in a way that is also understood by the manufacturer (implementer). This plan uses a precise technical notation, which provides a means of communicating precisely the user?s needs to the implementer (manufacturer), in a form that can be understood by both. Manufacture only begins after the customer has agreed the specification. Manufacture uses a different, but closely related set of plans, which specify the exact materials and products to be used down to the precise specification of every last screw. This is the ITS. RMIMs are useful to technologists as summary documents and the hyper-links are genuinely helpful for navigating round the tabular views (rather in the same way that use case diagrams have a value as a contents list for detailed use case descriptions). When finalising what is to be done (Use 1), we need a specification which can be understood properly by domain experts, integration engineers and software developers. In a simple one-to-one interface there will be at least five roles: 2 domain experts (one at each end), 2 sets of software developers (one at each end) and the integration engineer(s). As we scale up to large numbers of parties, the numbers increase exponentially. When it comes to implementation (Use 2), we need technical specifications which have to be interpreted precisely, unambiguously and without deviation by the 2 sets of software developers and the integration engineer(s). Traditional software development is a much easier problem because there is usually only one customer (domain expert) and one set of developers (technical experts). Solutions which work for this relatively simple problem are unlikely to scale to a more complex problems like ours! Before we despair, we should remember two factors that simplify the problem greatly. First, interoperability specifications deal only with the exchange of data (the static content of computer files and messages), not with manipulating that data (data processing), and second, they cover only the subset of data, which is to be shared with other computers. Best wishes Tim On 22/7/06 11:55 Grahame Grieve wrote: > hi Tim > > I can follow your argument. I'm not sure that I agree though. > > I guess that the question is whether the fact that RMIMs are > not understandable to the domain expert in the street means > that they are PSMs, or whether it means they are failed PIMs. > I don't think that any technologist would understand them > as a useful technology specification either. > > All PIMS are also PSMs, but the platform the are specific for > has mappings to other platforms, usually useful platforms for > implementation. > > But I can see the logic that the DAM is closer to a PIM too. > > I guess this shows that > a) HL7 is a standards developer, not an application developer > b) we don't do what we are doing very well > c) there is a loose correlation between the system design > approach - like between MDA, RM-ODP, TOGAF, etc > > Grahame > > Tim Benson wrote: >> Graham, >> >> I am responding to your piece on the wiki about MDA. >> >> One of the myths in the HL7 methodology is that there is rough >> correspondence between MDA and HL7 HDF. This myth originates from linking >> the original work in CEN TC251, which developed the idea of >> syntax-independent standard message specifications (General Message >> Descriptions) that could be implemented in various different syntaxes, with >> the MDA paradigm. >> >> The conventional view is: >> >> CIM => DAM >> PIM => RMIM >> PSM => ITS >> >> The MDA is a useful framework, but it was designed for writing software >> applications not for messaging. My understanding is: >> >> CIM describes the high-level business processes of the proposed system and >> is typically documented using use case descriptions and activity diagrams. >> Class models in CIMs are sketches and not prescriptive. The purpose is to >> define the scope and all of the business processes that are to be supported. >> >> PIM is a stringent specification of the logical design of the system, >> covering all details that are of interest to the user or domain expert at >> each end. This must be understood by, reviewed by and approved by the >> domain experts as well as by the technology experts. It is the basis of the >> contract between users at each end, their software developers and the >> integration engineers. >> >> PSM is the precise specification of what is to be built. It is technology >> specific and only needs to be understood by technology experts (integration >> engineers and software developers at each end). >> >> It is now accepted that "the domain expert in the street" (to use Charlie >> Mead's term) cannot safely understand RMIMs and other RIM-based artefacts. >> The consequence of this key fact is that these artefacts should be regarded >> as PSM, not PIM artefacts. >> >> RIM-based artefacts are PSM artefacts used by technology experts and should >> not be used in reviewing message designs with domain experts. We need to >> put much more work into developing genuine PIMs, which may be referred to as >> DAM Profiles. >> >> A DAM Profile is a precise logical design specification of a single message >> to do a single job. It makes sense, for reasons I will not go into here, to >> develop DAM Profiles as specific views into a larger model - the DAM. >> >> If these arguments are accepted, the relationship between MDA and HL7 should >> read: >> >> CIM => Scope and Business Process Model >> PIM => DAM or DAM Profile(s) >> PSM => RMIM and ITS >> >> Best wishes >> >> Tim >> >> >> >> >> >> >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> From grahame at kestral.com.au Mon Jul 24 03:54:42 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 24 Jul 2006 12:54:42 +1000 Subject: [New-ITS] Element Namg Consistency Message-ID: <44C43672.4030708@kestral.com.au> Hi All. From the message simplication notes last week: "The group agreed that removing some structural attributes might be safe, but we would need to be selective .. the impact on semantic processing would need to be tested" and "in order to support semantic processing while avoiding the inclusion of structural attributes in the instance, full-strength element name consistency is required across generations of the same messages, as well as across closely-related messages. This would require a consistency in the positioning of corresponding elements in instances with respect to the message model. Greater consistency in model element names should support a predictable path (given a node in context) to XML element names" and "The group agreed that if element names were consistent, removing structural attributes from instances would be more acceptable" So, this implies that at least one vendor actually has generic code that is coded to ignore names and use structural attributes in order to recognise concepts in the V3 messages. Yet it's not clear that "a consistency of positioning of corresponding elements" (whatever that might mean), or "full-strength element name consistency" begins to replace the structural attributes in the instance, unless the element names are direct hybrids of the structural attributes. The feedback we had got to this point is that such generic cross-message processing didn't occur, and so we have been pursuing a course of action that actually makes this kind of processing more expensive, not less expensive. There was some discussion about the cost of using PSVI. Basically, if the attributes are removed from the instance, there will be a processing price. PSVI is one of several ways to extract the attribute values from the definitions if they are not found in the instance. Hardcoding the transforms or program code is another. You cannot have it both ways - either they are in the instance, or they are found from somewhere else, and either way, there is a price to pay. Grahame From Robert.Worden at Charteris.com Mon Jul 24 09:13:26 2006 From: Robert.Worden at Charteris.com (Robert Worden) Date: Mon, 24 Jul 2006 09:13:26 +0100 Subject: [New-ITS] RMIM shaper tool first release Message-ID: All I have now got the RMIM shaper tool (which was discussed at the last HL7 UK TC meeting) to a state robust enough for others to try it, although you may find glitches. To get a copy of the tool, email me. The User Guide (11 pages) is attached. (Laura - could we put the tool somewhere with open access for anyone to download?) What the tool does: You first load it with an RMIM, in the form of a MIF file, attendant CMETs and a data types schema. Then you start restricting and reshaping the RMIM, e.g. restricting cardinalities of associations, collapsing associations, renaming classes. The aim of this is to make the RMIM simpler and more like a domain analysis model (DAM); but for it to convey the same semantics. I loosely refer to the reshaped RMIM as a DAM. You can put in instance values of properties anywhere in the RMIM tree, to go in exemplar messages. The tool can then output: - a basic MIF file for the DAM - the set of mappings from DAM to RMIM, so you can restart later and do more reshaping - exemplar message instances, in either RMIM form (i.e XML ITS) or DAM-based XML (simpler) - containing just the instance values you put in, and fixed values. I next plan to do round-trip translation between RMIM and DAM XML forms. Please try out the tool and tell me any problems. If you do examples, please tell me about them or post them here. The tool kit pack is about 700KB and has sample files to get you going. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060724/3d06de64/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Using the RMIM Shaper Tool.doc Type: application/msword Size: 171520 bytes Desc: Using the RMIM Shaper Tool.doc Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060724/3d06de64/UsingtheRMIMShaperTool-0001.doc From Laura.Sato at cfh.nhs.uk Mon Jul 24 15:29:31 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Mon, 24 Jul 2006 15:29:31 +0100 Subject: [New-ITS] RMIM shaper tool first release Message-ID: <1A3D105C334EAE49BDDD93D8767573F50407C0EE@EXCHAQ2.nhsia.nhs.uk> All, fyi - Robert's proof of concept tool is now downloadable from the HL7 Tooling Committee site, at http://www.hl7.org/library/committees/v3ttf/shaper%2Ezip. Best regards, Laura -----Original Message----- From: Robert Worden [mailto:Robert.Worden at Charteris.com] Sent: 24 July 2006 09:13 To: new-its at lists.hl7.org.uk Cc: Sato Laura Subject: RMIM shaper tool first release All I have now got the RMIM shaper tool (which was discussed at the last HL7 UK TC meeting) to a state robust enough for others to try it, although you may find glitches. To get a copy of the tool, email me. The User Guide (11 pages) is attached. (Laura - could we put the tool somewhere with open access for anyone to download?) What the tool does: You first load it with an RMIM, in the form of a MIF file, attendant CMETs and a data types schema. Then you start restricting and reshaping the RMIM, e.g. restricting cardinalities of associations, collapsing associations, renaming classes. The aim of this is to make the RMIM simpler and more like a domain analysis model (DAM); but for it to convey the same semantics. I loosely refer to the reshaped RMIM as a DAM. You can put in instance values of properties anywhere in the RMIM tree, to go in exemplar messages. The tool can then output: - a basic MIF file for the DAM - the set of mappings from DAM to RMIM, so you can restart later and do more reshaping - exemplar message instances, in either RMIM form (i.e XML ITS) or DAM-based XML (simpler) - containing just the instance values you put in, and fixed values. I next plan to do round-trip translation between RMIM and DAM XML forms. Please try out the tool and tell me any problems. If you do examples, please tell me about them or post them here. The tool kit pack is about 700KB and has sample files to get you going. Robert Charteris plc, Charteris House, 39/40 Bartholomew Close, London EC1A 7JN phone: 44 1353 777668; Fax 44 1353 777394; mobile: 44 7970 197968 *************************** E-mail confidentiality notice ******************************* This message is intended for the addressee only. It is private, confidential and may contain information of a proprietary nature. If you have received this message in error, please notify us and remove it from your system. _________________________________________________________________ This message from Charteris plc has been checked for viruses http://www.charteris.com/ This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060724/16e30c29/attachment.htm From Laura.Sato at cfh.nhs.uk Mon Jul 24 15:50:57 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Mon, 24 Jul 2006 15:50:57 +0100 Subject: [New-ITS] implementer input request Message-ID: <1A3D105C334EAE49BDDD93D8767573F50407C11A@EXCHAQ2.nhsia.nhs.uk> Hello, It's come up a couple of times during ITS (and other message 'simplification' discussions) that it would be useful to know what approaches are currently taken (or are planned to be taken) in the semantic processing of messages. I'll be sending out a general request for input on this to NPfIT suppliers, but if anyone on this list can tell me (e.g. in a paragraph or two) what approach their applications are taking (e.g. are CSMP-driven processers being developed? what other mechanisms are being used?) I would really appreciate it. I'd then collate the results for our study so that we can have a better feel for the impact of changes on instances (e.g. on removing structural attributes) during the ITS investigation. Best regards, Laura ________________________________________ Laura Sato Informatics Standards Lead Communications & Messaging NHS Connecting for Health Mobile : (44) (0)7733 324338 Email: laura.sato at cfh.nhs.uk Web: www.connectingforhealth.nhs.uk This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060724/7939e8d8/attachment.htm From grahame at kestral.com.au Tue Jul 25 02:34:36 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 25 Jul 2006 11:34:36 +1000 Subject: [New-ITS] HL7 and MDA In-Reply-To: References: Message-ID: <44C5752C.4070302@kestral.com.au> I slipped up when I responded just to you - this discussion should be on the list. Yep, we all know and love USAM. I understand what you are saying: * RMIMS are not understandable by domain experts * Therefore RMIMS are not proper PIMs * So we should make DAMS into PIMs and let RMIMs be PSMs (tell me if I've got it wrong) But I say: * RMIMs are not understandable by domain experts * RMIMs are not understandable by technologists either * pretending that RMIMs can be PSMs isn't going to help anyone * Let's introduce a new model (Implementable Model) which is intended to be a PSM * Let's define the qualities of your "stringent, understandable, reviewable, checkable and signed off by the domain expert on the street" model and find out where it fits into the HDF. Maybe it is the DAM, maybe not. Grahame > The original purpose (10 years ago) of RMIMs was that they would be > stringent, understandable, reviewable, checkable and signed off by the > "domain expert on the street". Note the use of the term domain expert, > rather than user. These ideas were implicit in the HL7 MDF, Version 3.3 > (1999). > > The V3 RIM, prior to V0.94 (2000) (which was the first RIM to begin adopting > USAM principles), contained classes and attributes which *could* be > understood by the domain expert on the street. The trouble was that the > 1999 RIM was so large that standards makers could not use it and the tools > were inadequate (being distributed using Excel). > > The introduction of USAM in the 2000/1 version of the RIM led to a dramatic > simplification, down to the simple backbone we have come to know and love. > USAM introduced a completely new "language" which has effectively meant that > only fluent speakers of that language can understand USAM-based documents. > > Although the downside was not recognised by most people at the time, the > consequence is that no USAM-based documents meet the criterion of being: > "stringent, understandable, reviewable, checkable and signed off by the > domain expert on the street". > > The new RMIMs (post-2000) do NOT meet this basic requirement. You need to > speak USAM to understand them. > > The difference between pre-USAM RMIMs and the present generation is well > illustrated by the attached image which is taken from the latest MDF (page > 168). This does not, in my opinion, fully meet the requirements (lets not > get into that here) but it is much closer to meeting the "domain expert on > the street" criterion than any 2006 RMIM. If you like I can draw up a 2006 > Visio version for comparison, but I think you can imagine it. > > This analysis gives us two alternatives: > > (1) Go back to 1999 and revive the old RIM, which I really do not think is > practical politics, even though the downside of USAM is becoming clear. > > (2) Add a new artefact which is "stringent, understandable, reviewable, > checkable and signed off by the domain expert on the street" before mapping > this into USAM. > > My proposal is option (2). > > Does this help? > > Tim > > PS I note that this is now a private conversation. > > > > > > On 24/7/06 03:00 Grahame Grieve wrote: > >> Hi Tim >> >>> My point is that we need two specifications (1) A specification of the user >>> requirement, which is understood by everyone (including users and domain >>> experts); (2) A specification of what goes over the wire, which only needs >>> to be understood by techies. >>> >>> Both specifications need to be stringent and leave nothing to to individual >>> implementation choice. In MDA, PIMs do job (1) and PSMs do job (2). >> good we agree about that. >> >>> In HL7 V3 terminology, the DAM Profile to refers to (1) and RIM-based >>> artefacts to refer to (2). >> we don't agree about that. >> >>> HL7 does not have a culture of stringent specification of user requirements, >>> which is the problem. >> yes, we agree about that. >> >>> It does not matter so much when you are doing simple >>> one-to-one interfaces, because the integration engineer >> a who? I've *never* worked with one of those. Maybe this is an Australian >> thing. >> >>> One of the problems is one of terminology. It is always difficult to >>> describe something that is "new". Reference to MDA is helpful only if we do >>> not claim that RMIMs are really PIMs! PIMs have to be fully understood by >>> "the domain expert on the street". >> so, you argue that RMIMs are not PIMs because they are not understood by >> the "domain expert on the street". And therefore they are PSMs. But I don't >> agree. The RMIMs are *intended* to be PIMs. Just because they fail, that >> doesn't >> change what their intent is. >> >>> The argument that RMIM+ITS can fulfil both roles is as much wishful thinking >> why is it wishful thinking? Why must there be an extra layer of modeling for >> implementation? Perhaps you could illuminate us with a case study.... >> >> Grahame >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From tim.benson at abies.co.uk Tue Jul 25 09:07:02 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Tue, 25 Jul 2006 09:07:02 +0100 Subject: [New-ITS] FW: HL7 and MDA In-Reply-To: Message-ID: For anyone following this thread, some of this missed the list. Tim ------ Forwarded Message From: Tim Benson Date: Sun, 23 Jul 2006 10:01:02 +0100 To: , Grahame Grieve Conversation: [New-ITS] HL7 and MDA Subject: Re: [New-ITS] HL7 and MDA Hi Grahame My point is that we need two specifications (1) A specification of the user requirement, which is understood by everyone (including users and domain experts); (2) A specification of what goes over the wire, which only needs to be understood by techies. Both specifications need to be stringent and leave nothing to to individual implementation choice. In MDA, PIMs do job (1) and PSMs do job (2). In HL7 V3 terminology, the DAM Profile to refers to (1) and RIM-based artefacts to refer to (2). In HL7 V2, everything is job (2)! HL7 does not have a culture of stringent specification of user requirements, which is the problem. It does not matter so much when you are doing simple one-to-one interfaces, because the integration engineer can talk to everyone, but it is, I think, invaluable for any project involving many participants. Most people in HL7 do not even recognise that it would be a step forward. One of the problems is one of terminology. It is always difficult to describe something that is "new". Reference to MDA is helpful only if we do not claim that RMIMs are really PIMs! PIMs have to be fully understood by "the domain expert on the street". The argument that RMIM+ITS can fulfil both roles is as much wishful thinking as Grace Murray Hopper's belief that company accountants could check COBOL source code. Roughly, RMIM is to COBOL as ITS (XML) is to Machine code. Tim On 22/7/06 20:17 Grahame Grieve wrote: > Hi Tim > > I'm left wondering quite what your point is. > > I still stick to my view that the mapping is unclear. > The DAM as we have them isn't quite the customer specification. It's > more like a detailed view of the customers idea's of what they > want. The RMIM+ITS is intended to full both roles. > > But does it really matter that we disagree here? You say that this > is at the heart of our problems, but I don't see it? > > Grahame > > > > Tim Benson wrote: >> Hi Grahame, >> >> Apologies for a verbose response, but I feel that this issue is right at the >> heart of our problems. In any design and build operation there are usually >> at least two specifications. The useful distinction is what a specification >> is used for, not whether it is or is not specific to a particular platform >> or technology. >> >> I recognise two fundamental uses for specifications (blueprints). >> >> The first is between the customer and the service provider, which specifies >> clearly what the customer will get. This is the basis of the contract >> between them. This specification is the exact equivalent of the PIM or DAM >> Profile. >> >> The second type of specification, which is only used in manufacture, is the >> exact equivalent of the PSM. This is the technical specification which is >> used in the actual build. >> >> An analogy is the purchase of a new kitchen. The kitchen designer prepares >> a detailed plan of the new kitchen. This plan is checked, reviewed and >> signed off by the customer and is the basis of the contract. All of the >> details that are important to the user (sizes, colour etc.) are specified >> precisely and agreed with the customer in a way that is also understood by >> the manufacturer (implementer). This plan uses a precise technical >> notation, which provides a means of communicating precisely the user?s needs >> to the implementer (manufacturer), in a form that can be understood by both. >> >> Manufacture only begins after the customer has agreed the specification. >> Manufacture uses a different, but closely related set of plans, which >> specify the exact materials and products to be used down to the precise >> specification of every last screw. This is the ITS. RMIMs are useful to >> technologists as summary documents and the hyper-links are genuinely helpful >> for navigating round the tabular views (rather in the same way that use case >> diagrams have a value as a contents list for detailed use case >> descriptions). >> >> When finalising what is to be done (Use 1), we need a specification which >> can be understood properly by domain experts, integration engineers and >> software developers. In a simple one-to-one interface there will be at >> least five roles: 2 domain experts (one at each end), 2 sets of software >> developers (one at each end) and the integration engineer(s). As we scale >> up to large numbers of parties, the numbers increase exponentially. >> >> When it comes to implementation (Use 2), we need technical specifications >> which have to be interpreted precisely, unambiguously and without deviation >> by the 2 sets of software developers and the integration engineer(s). >> >> Traditional software development is a much easier problem because there is >> usually only one customer (domain expert) and one set of developers >> (technical experts). Solutions which work for this relatively simple >> problem are unlikely to scale to a more complex problems like ours! >> >> Before we despair, we should remember two factors that simplify the problem >> greatly. First, interoperability specifications deal only with the exchange >> of data (the static content of computer files and messages), not with >> manipulating that data (data processing), and second, they cover only the >> subset of data, which is to be shared with other computers. >> >> Best wishes >> >> Tim >> >> >> On 22/7/06 11:55 Grahame Grieve wrote: >> >>> hi Tim >>> >>> I can follow your argument. I'm not sure that I agree though. >>> >>> I guess that the question is whether the fact that RMIMs are >>> not understandable to the domain expert in the street means >>> that they are PSMs, or whether it means they are failed PIMs. >>> I don't think that any technologist would understand them >>> as a useful technology specification either. >>> >>> All PIMS are also PSMs, but the platform the are specific for >>> has mappings to other platforms, usually useful platforms for >>> implementation. >>> >>> But I can see the logic that the DAM is closer to a PIM too. >>> >>> I guess this shows that >>> a) HL7 is a standards developer, not an application developer >>> b) we don't do what we are doing very well >>> c) there is a loose correlation between the system design >>> approach - like between MDA, RM-ODP, TOGAF, etc >>> >>> Grahame >>> >>> Tim Benson wrote: >>>> Graham, >>>> >>>> I am responding to your piece on the wiki about MDA. >>>> >>>> One of the myths in the HL7 methodology is that there is rough >>>> correspondence between MDA and HL7 HDF. This myth originates from linking >>>> the original work in CEN TC251, which developed the idea of >>>> syntax-independent standard message specifications (General Message >>>> Descriptions) that could be implemented in various different syntaxes, with >>>> the MDA paradigm. >>>> >>>> The conventional view is: >>>> >>>> CIM => DAM >>>> PIM => RMIM >>>> PSM => ITS >>>> >>>> The MDA is a useful framework, but it was designed for writing software >>>> applications not for messaging. My understanding is: >>>> >>>> CIM describes the high-level business processes of the proposed system and >>>> is typically documented using use case descriptions and activity diagrams. >>>> Class models in CIMs are sketches and not prescriptive. The purpose is to >>>> define the scope and all of the business processes that are to be >>>> supported. >>>> >>>> PIM is a stringent specification of the logical design of the system, >>>> covering all details that are of interest to the user or domain expert at >>>> each end. This must be understood by, reviewed by and approved by the >>>> domain experts as well as by the technology experts. It is the basis of >>>> the >>>> contract between users at each end, their software developers and the >>>> integration engineers. >>>> >>>> PSM is the precise specification of what is to be built. It is technology >>>> specific and only needs to be understood by technology experts (integration >>>> engineers and software developers at each end). >>>> >>>> It is now accepted that "the domain expert in the street" (to use Charlie >>>> Mead's term) cannot safely understand RMIMs and other RIM-based artefacts. >>>> The consequence of this key fact is that these artefacts should be regarded >>>> as PSM, not PIM artefacts. >>>> >>>> RIM-based artefacts are PSM artefacts used by technology experts and should >>>> not be used in reviewing message designs with domain experts. We need to >>>> put much more work into developing genuine PIMs, which may be referred to >>>> as >>>> DAM Profiles. >>>> >>>> A DAM Profile is a precise logical design specification of a single message >>>> to do a single job. It makes sense, for reasons I will not go into here, >>>> to >>>> develop DAM Profiles as specific views into a larger model - the DAM. >>>> >>>> If these arguments are accepted, the relationship between MDA and HL7 >>>> should >>>> read: >>>> >>>> CIM => Scope and Business Process Model >>>> PIM => DAM or DAM Profile(s) >>>> PSM => RMIM and ITS >>>> >>>> Best wishes >>>> >>>> Tim >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >> >> >> ------ End of Forwarded Message From tim.benson at abies.co.uk Wed Jul 26 15:55:08 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Wed, 26 Jul 2006 15:55:08 +0100 Subject: [New-ITS] HL7 and MDA In-Reply-To: <44C5752C.4070302@kestral.com.au> Message-ID: Grahame, I think that we are almost there. (1) We both agree that we need a stringent, understandable, reviewable, checkable version of the specification, which can be signed off by the domain expert on the street. Lets call this Type (1). (2) We both agree that implementers need precise unambiguous blueprints to implement messages unambiguously, so they pass stringent conformance tests first time. Lets call this Type (2). (3) We both agree that the RMIM does not meet either requirement. The conclusion is that we need two new types of specification one for Type (1) and for Type (2) above. This gives rise to several sub-issues: (a) Type (1) and Type (2) specifications need to mean exactly the same in terms of semantic content exchanged. It should be possible to map both ways between them. (b) Does the existing RMIM have any value at all? If it does have any future, then is it anything more than as a contents page for Type (2) specifications? This is analogous to the relationship between use case diagrams (with their stick men) and detailed use case descriptions. (c) We are agreed that Type (1) specifications *cannot* be based on the USAM RIM, but is it a "given" that the Type (2) specifications are to be based on the post-USAM RIM? I have always made this assumption, but I would like to see it confirmed. (d) Is everyone happy to use the use MDA terms of PIM for Type (1) and PSM for Type (2)? As someone with very mild dyslexia, I find these acronyms to be easily confused, but this may be only a matter of familiarity. Do we need to worry about CIMs? MDA is designed for developing object software and are we likely to import some irrelevant baggage if we swallow it hook, line and sinker? If we do need to find some new names for things, perhaps we should look again at CEN TC251's CR 12587:1997 Methodology for the Development of Healthcare Messages, which uses specific well-defined terms like General Message Description (GMD) for Type (1) and Implementable Message Specification (IMS) for Type (2). Tim On 25/7/06 02:34 Grahame Grieve wrote: > I slipped up when I responded just to you - this discussion > should be on the list. > > Yep, we all know and love USAM. > > I understand what you are saying: > > * RMIMS are not understandable by domain experts > * Therefore RMIMS are not proper PIMs > * So we should make DAMS into PIMs and let RMIMs be PSMs > > (tell me if I've got it wrong) > > But I say: > * RMIMs are not understandable by domain experts > * RMIMs are not understandable by technologists either > * pretending that RMIMs can be PSMs isn't going to help anyone > * Let's introduce a new model (Implementable Model) which is > intended to be a PSM > * Let's define the qualities of your "stringent, understandable, > reviewable, checkable and signed off by the domain expert on > the street" model and find out where it fits into the HDF. > Maybe it is the DAM, maybe not. > > Grahame > > > > >> The original purpose (10 years ago) of RMIMs was that they would be >> stringent, understandable, reviewable, checkable and signed off by the >> "domain expert on the street". Note the use of the term domain expert, >> rather than user. These ideas were implicit in the HL7 MDF, Version 3.3 >> (1999). >> >> The V3 RIM, prior to V0.94 (2000) (which was the first RIM to begin adopting >> USAM principles), contained classes and attributes which *could* be >> understood by the domain expert on the street. The trouble was that the >> 1999 RIM was so large that standards makers could not use it and the tools >> were inadequate (being distributed using Excel). >> >> The introduction of USAM in the 2000/1 version of the RIM led to a dramatic >> simplification, down to the simple backbone we have come to know and love. >> USAM introduced a completely new "language" which has effectively meant that >> only fluent speakers of that language can understand USAM-based documents. >> >> Although the downside was not recognised by most people at the time, the >> consequence is that no USAM-based documents meet the criterion of being: >> "stringent, understandable, reviewable, checkable and signed off by the >> domain expert on the street". >> >> The new RMIMs (post-2000) do NOT meet this basic requirement. You need to >> speak USAM to understand them. >> >> The difference between pre-USAM RMIMs and the present generation is well >> illustrated by the attached image which is taken from the latest MDF (page >> 168). This does not, in my opinion, fully meet the requirements (lets not >> get into that here) but it is much closer to meeting the "domain expert on >> the street" criterion than any 2006 RMIM. If you like I can draw up a 2006 >> Visio version for comparison, but I think you can imagine it. >> >> This analysis gives us two alternatives: >> >> (1) Go back to 1999 and revive the old RIM, which I really do not think is >> practical politics, even though the downside of USAM is becoming clear. >> >> (2) Add a new artefact which is "stringent, understandable, reviewable, >> checkable and signed off by the domain expert on the street" before mapping >> this into USAM. >> >> My proposal is option (2). >> >> Does this help? >> >> Tim >> >> PS I note that this is now a private conversation. >> >> >> >> >> >> On 24/7/06 03:00 Grahame Grieve wrote: >> >>> Hi Tim >>> >>>> My point is that we need two specifications (1) A specification of the user >>>> requirement, which is understood by everyone (including users and domain >>>> experts); (2) A specification of what goes over the wire, which only needs >>>> to be understood by techies. >>>> >>>> Both specifications need to be stringent and leave nothing to to individual >>>> implementation choice. In MDA, PIMs do job (1) and PSMs do job (2). >>> good we agree about that. >>> >>>> In HL7 V3 terminology, the DAM Profile to refers to (1) and RIM-based >>>> artefacts to refer to (2). >>> we don't agree about that. >>> >>>> HL7 does not have a culture of stringent specification of user >>>> requirements, >>>> which is the problem. >>> yes, we agree about that. >>> >>>> It does not matter so much when you are doing simple >>>> one-to-one interfaces, because the integration engineer >>> a who? I've *never* worked with one of those. Maybe this is an Australian >>> thing. >>> >>>> One of the problems is one of terminology. It is always difficult to >>>> describe something that is "new". Reference to MDA is helpful only if we >>>> do >>>> not claim that RMIMs are really PIMs! PIMs have to be fully understood by >>>> "the domain expert on the street". >>> so, you argue that RMIMs are not PIMs because they are not understood by >>> the "domain expert on the street". And therefore they are PSMs. But I don't >>> agree. The RMIMs are *intended* to be PIMs. Just because they fail, that >>> doesn't >>> change what their intent is. >>> >>>> The argument that RMIM+ITS can fulfil both roles is as much wishful >>>> thinking >>> why is it wishful thinking? Why must there be an extra layer of modeling for >>> implementation? Perhaps you could illuminate us with a case study.... >>> >>> Grahame >>> >>> >> From MelvinR at AMS-Consulting.co.uk Wed Jul 26 21:40:56 2006 From: MelvinR at AMS-Consulting.co.uk (Melvin Reynolds) Date: Wed, 26 Jul 2006 21:40:56 +0100 Subject: [New-ITS] HL7 and MDA In-Reply-To: References: <44C5752C.4070302@kestral.com.au> Message-ID: Tim, Just trying to clarify things in my mind - but without the benefit of deep (OK, pretty much any) knowledge of MDA. In ISO/IEC JTC1-speak a PSM is a Persistent Stored Module, and in OMG- speak it means Platform Specific Model. - Pretty confusing because they are close enough in use domain! I suggest that PSM is sufficiently ambiguous that it should be deprecated. PIM seems to be less problematic (neither Personal information manager nor Protocol Independent Multicast seem likely to be confused). That leaves us casting around for an acceptable (presumably paired) alternative. Your suggestion (General Message Description (GMD) for Type (1) and Implementable Message Specification (IMS) for Type (2)) appears not to involve any ambiguities - though I can imagine that some might baulk at the use of 'Message'. ... and that always assumes that there is consensus about your Type (1) and Type (2) 'requirements'! Best regards, Melvin. In mail of Wed, 26 Jul 2006 15:55:08, Tim Benson wrote: >Grahame, > >I think that we are almost there. > >(1) We both agree that we need a stringent, understandable, reviewable, >checkable version of the specification, which can be signed off by the >domain expert on the street. Lets call this Type (1). > >(2) We both agree that implementers need precise unambiguous blueprints to >implement messages unambiguously, so they pass stringent conformance tests >first time. Lets call this Type (2). > >(3) We both agree that the RMIM does not meet either requirement. The >conclusion is that we need two new types of specification one for Type (1) >and for Type (2) above. > >This gives rise to several sub-issues: > >(a) Type (1) and Type (2) specifications need to mean exactly the same in >terms of semantic content exchanged. It should be possible to map both ways >between them. > >(b) Does the existing RMIM have any value at all? If it does have any >future, then is it anything more than as a contents page for Type (2) >specifications? This is analogous to the relationship between use case >diagrams (with their stick men) and detailed use case descriptions. > >(c) We are agreed that Type (1) specifications *cannot* be based on the USAM >RIM, but is it a "given" that the Type (2) specifications are to be based on >the post-USAM RIM? I have always made this assumption, but I would like to >see it confirmed. > >(d) Is everyone happy to use the use MDA terms of PIM for Type (1) and PSM >for Type (2)? As someone with very mild dyslexia, I find these acronyms to >be easily confused, but this may be only a matter of familiarity. Do we >need to worry about CIMs? MDA is designed for developing object software >and are we likely to import some irrelevant baggage if we swallow it hook, >line and sinker? If we do need to find some new names for things, perhaps we >should look again at CEN TC251's CR 12587:1997 Methodology for the >Development of Healthcare Messages, which uses specific well-defined terms >like General Message Description (GMD) for Type (1) and Implementable >Message Specification (IMS) for Type (2). > >Tim > >On 25/7/06 02:34 Grahame Grieve wrote: > >> I slipped up when I responded just to you - this discussion >> should be on the list. >> >> Yep, we all know and love USAM. >> >> I understand what you are saying: >> >> * RMIMS are not understandable by domain experts >> * Therefore RMIMS are not proper PIMs >> * So we should make DAMS into PIMs and let RMIMs be PSMs >> >> (tell me if I've got it wrong) >> >> But I say: >> * RMIMs are not understandable by domain experts >> * RMIMs are not understandable by technologists either >> * pretending that RMIMs can be PSMs isn't going to help anyone >> * Let's introduce a new model (Implementable Model) which is >> intended to be a PSM >> * Let's define the qualities of your "stringent, understandable, >> reviewable, checkable and signed off by the domain expert on >> the street" model and find out where it fits into the HDF. >> Maybe it is the DAM, maybe not. >> >> Grahame >> >> >> >> >>> The original purpose (10 years ago) of RMIMs was that they would be >>> stringent, understandable, reviewable, checkable and signed off by the >>> "domain expert on the street". Note the use of the term domain expert, >>> rather than user. These ideas were implicit in the HL7 MDF, Version 3.3 >>> (1999). >>> >>> The V3 RIM, prior to V0.94 (2000) (which was the first RIM to begin adopting >>> USAM principles), contained classes and attributes which *could* be >>> understood by the domain expert on the street. The trouble was that the >>> 1999 RIM was so large that standards makers could not use it and the tools >>> were inadequate (being distributed using Excel). >>> >>> The introduction of USAM in the 2000/1 version of the RIM led to a dramatic >>> simplification, down to the simple backbone we have come to know and love. >>> USAM introduced a completely new "language" which has effectively meant that >>> only fluent speakers of that language can understand USAM-based documents. >>> >>> Although the downside was not recognised by most people at the time, the >>> consequence is that no USAM-based documents meet the criterion of being: >>> "stringent, understandable, reviewable, checkable and signed off by the >>> domain expert on the street". >>> >>> The new RMIMs (post-2000) do NOT meet this basic requirement. You need to >>> speak USAM to understand them. >>> >>> The difference between pre-USAM RMIMs and the present generation is well >>> illustrated by the attached image which is taken from the latest MDF (page >>> 168). This does not, in my opinion, fully meet the requirements (lets not >>> get into that here) but it is much closer to meeting the "domain expert on >>> the street" criterion than any 2006 RMIM. If you like I can draw up a 2006 >>> Visio version for comparison, but I think you can imagine it. >>> >>> This analysis gives us two alternatives: >>> >>> (1) Go back to 1999 and revive the old RIM, which I really do not think is >>> practical politics, even though the downside of USAM is becoming clear. >>> >>> (2) Add a new artefact which is "stringent, understandable, reviewable, >>> checkable and signed off by the domain expert on the street" before mapping >>> this into USAM. >>> >>> My proposal is option (2). >>> >>> Does this help? >>> >>> Tim >>> >>> PS I note that this is now a private conversation. >>> >>> >>> >>> >>> >>> On 24/7/06 03:00 Grahame Grieve wrote: >>> >>>> Hi Tim >>>> >>>>> My point is that we need two specifications (1) A specification of >>>>>the user >>>>> requirement, which is understood by everyone (including users and domain >>>>> experts); (2) A specification of what goes over the wire, which only needs >>>>> to be understood by techies. >>>>> >>>>> Both specifications need to be stringent and leave nothing to to >>>>>individual >>>>> implementation choice. In MDA, PIMs do job (1) and PSMs do job (2). >>>> good we agree about that. >>>> >>>>> In HL7 V3 terminology, the DAM Profile to refers to (1) and RIM-based >>>>> artefacts to refer to (2). >>>> we don't agree about that. >>>> >>>>> HL7 does not have a culture of stringent specification of user >>>>> requirements, >>>>> which is the problem. >>>> yes, we agree about that. >>>> >>>>> It does not matter so much when you are doing simple >>>>> one-to-one interfaces, because the integration engineer >>>> a who? I've *never* worked with one of those. Maybe this is an Australian >>>> thing. >>>> >>>>> One of the problems is one of terminology. It is always difficult to >>>>> describe something that is "new". Reference to MDA is helpful only if we >>>>> do >>>>> not claim that RMIMs are really PIMs! PIMs have to be fully understood by >>>>> "the domain expert on the street". >>>> so, you argue that RMIMs are not PIMs because they are not understood by >>>> the "domain expert on the street". And therefore they are PSMs. But I don't >>>> agree. The RMIMs are *intended* to be PIMs. Just because they fail, that >>>> doesn't >>>> change what their intent is. >>>> >>>>> The argument that RMIM+ITS can fulfil both roles is as much wishful >>>>> thinking >>>> why is it wishful thinking? Why must there be an extra layer of >>>>modeling for >>>> implementation? Perhaps you could illuminate us with a case study.... >>>> >>>> Grahame >>>> >>>> >>> > > >_______________________________________________ >New-ITS mailing list >New-ITS at lists.hl7.org.uk >http://lists.hl7.org.uk/mailman/listinfo/new-its -- Melvin I REYNOLDS, ~ Setting Standards for Information, Management & Technology in Care ~ AMS Consulting ~ Ashcote ~ Walford Road ~ Ross-on-Wye ~ HR9 5PQ ~ UK email: melvinr at ams-consulting.co.uk . . . . fax: +44 (0)8700 547 303 phone: +44 (0)1989 763 120 . . . . . . mobile: +44 (0)7831 517 803 . . . . . . . VOIP - skypeID: melvinreynolds . . . . . . ----------------------------------------------------------------------- The information contained in this e-mail may be confidential and / or copyright, and intended only for named recipient(s). If you have received it indirectly or in error please do not copy, distribute, take any action on, or rely on, the content; check authority for use with postmaster at ams-consulting.co.uk From tim.benson at abies.co.uk Fri Jul 28 08:39:46 2006 From: tim.benson at abies.co.uk (Tim Benson) Date: Fri, 28 Jul 2006 08:39:46 +0100 Subject: [New-ITS] FW: "Why is document an act?" In-Reply-To: Message-ID: If you are not on the mnm or structdoc list-servers you will have missed this thread, which echoes the debate on this list, during the past couple of weeks. Tim ------ Forwarded Message From: craig parker Eric Evans has written a book call "Domain-Driven Design" in which he talks about a Ubiquitous Language for talking about a domain. Here are a few quotes from the book. "A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design." ... "Translation blunts communication and makes knowledge crunching anemic." ... "Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design." "With a Ubiquitous Language, the model is not just a design artifact. It becomes integral to everything the developers and domain experts do together. The Language carries knowledge in a dynamic form. Discussion in the Language brings to life the meaning behind the diagrams and code." I think that the document issue points out the fact that V3 is not always a Ubiquitous Language. Often we have to translate between clinical-speak and RIM-speak. In some situations we only speak RIM-speak when Visio is open in front of us and we are trying to create a salmon-colored box that suits our needs. I would bet a large sum of money that people using the CDA seldom think about the act of documenting, but rather think in terms of a paper or electronic document. The problem is not that V3 is incapable of representing things we are interested in. The problem is that the V3 paradigm is not always one that is natural for communicating about certain subject areas. This forces us to use different languages when talking to different audiences (as Virginia and Calvin have both recently experienced). I believe that V3 has significant merit. I don't think we should throw it out just because it makes some things awkward to discuss. At the same time however, I don't think it is perfect. I think we should look for ways to improve V3 without invalidating the enormous effort that has gone into it so far. What could we do to make documents and conditions fit more naturally (to achieve a Ubiquitous Language)? Is V3 a closed system, or could it be extended in a non-destructive way? Would it be taboo to add a new type of class to the RIM (I vote for orange hexagons)? I wish I was smart enough to know the answer to these questions. Kind regards, Craig On 7/27/06, Lloyd McKenzie wrote: > Hi Craig, > > To a large extent, a "lab result" is thought of as a noun as well. > However, there's no question that the act of doing the observation is an > act. > > > Lloyd > > craig parker wrote: > > Keith, > > > > Your explantion is a nice, academic justification for why it is > > theoretically possible to say document is an act, but if you read the > > CDA spec, document is overwhelmingly used as a noun and not a verb, > > even in describing the document act. The only time anyone really > > talks about the verb "document" is when justifying the choice of > > making document an act. > > > > In describing section and body, the spec makes no effort at all to > > justify them as verbs or as acts. > > > > In reality, the RIM is act-centric. Making document an entity would > > have been very un-RIM-like. So we made document (a screw) into a nail > > so we could use our hammer. Let's just call a spade a spade and say > > "a document is not really an act, but it seemed to be the best way to > > model it in the RIM". > > > > -Craig > > > > > > On 7/27/06, Boone, Keith W (GE Healthcare) wrote: > >> Document is a verb and a noun. The verb is the act, the noun is the > >> product of that act. Document is an act the same way orders are acts, > >> or lab results are an act, or creating an image is an act. > >> > >> For the second half: Composition is an act, and documents are composed > >> of bodies, and bodies are composed of sections.... > >> The specific type of composition is organization...which is a > >> specialization of act, so bodies and sections are organizers. > >> > >> Will this question be on the certification test ;-) ? > >> > >> Keith > >> > >> > >> _________________________________ > >> Keith W. Boone > >> Lead Interoperability Systems Designer > >> GE Healthcare > >> 116 Huntington Ave > >> Boston, MA 02116 > >> USA > >> T +1.617.519.2076 > >> M +1.617.640.7007 > >> keith.boone at ge.com > >> www.gehealthcare.com > >> > >> -----Original Message----- > >> From: owner-strucdoc at lists.hl7.org [mailto:owner-strucdoc at lists.hl7.org] > >> On Behalf Of Virginia Lorenzi > >> Sent: Thursday, July 27, 2006 2:53 PM > >> To: mnm at lists.hl7.org; structdoc > >> Subject: "Why is document an act?" > >> > >> Both Calvin and I heard this question asked in our July summit classes. > >> > >> The answer was not that easy. > >> > >> How would you answer that question? For that matter, why are section > >> and body acts as well? > >> > >> > >> ************************************************ > >> You are currently subscribed to strucdoc at lists.hl7.org as > >> keith.boone at ge.com To unsubscribe from this list, send a blank email to > >> leave-strucdoc-375338P at lists.hl7.org > >> To access the Archives of this list, go to: > >> http://lists.hl7.org/read/?forum=strucdoc > >> To access your List Server profile and subscriptions, go to: > >> http://lists.hl7.org/read/login > >> > >> > >> ************************************************ > >> You are currently subscribed to strucdoc at lists.hl7.org as > >> craigparkermd at gmail.com > >> To unsubscribe from this list, send a blank email to > >> leave-strucdoc-375338P at lists.hl7.org > >> To access the Archives of this list, go to: > >> http://lists.hl7.org/read/?forum=strucdoc > >> To access your List Server profile and subscriptions, go to: > >> http://%%site.domainname%%/read/login > >> > > > > > > > ************************************************ > You are currently subscribed to strucdoc at lists.hl7.org as craigparkermd at gmail.com > To unsubscribe from this list, send a blank email to leave-strucdoc-375338P at lists.hl7.org > To access the Archives of this list, go to: http://lists.hl7.org/read/?forum=strucdoc > To access your List Server profile and subscriptions, go to: http://lists.hl7.org/read/login > -- Craig G. Parker, MD, MS Sr. Medical Informaticist Intermountain Healthcare m: +1 801.699.1295 {} ************************************************ You are currently subscribed to mnm at lists.hl7.org as tim.benson at abies.co.uk To unsubscribe from this list, send a blank email to leave-mnm-129180J at lists.hl7.org To access the Archives of this list, go to: http://lists.hl7.org/read/?forum=mnm To access your List Server profile and subscriptions, go to: http://lists.hl7.org/read/login ------ End of Forwarded Message From grahame at kestral.com.au Sun Jul 30 14:51:41 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Sun, 30 Jul 2006 23:51:41 +1000 Subject: [New-ITS] XMI Message-ID: <44CCB96D.8040603@kestral.com.au> I have been looking at the XMI serialisation. We could use it in the UML ITS, as the way that we specify how the XML reflects the UML diagrams. It has many strengths: 1. it's a standard (OMG no less), so tooling would exist 2. it allows you to do schemas (by all styles) and it lets you do DTDs (our current approach and the one I was going to propose do not allow anything but venetion blind schemas) 3. it is very name centric 4. it's very solid and proven 5. it has inbuilt support for id/idref resting on good standards under good control from the diagrams. 6. it allows all sorts of clever things like delta updates. it has some very strong weaknesses: 1. it allows all sorts of clever things like delta updates. 2. it is far more verbose than what I was going to propose or even the existing XML ITS (though the structural advantages we are pursuing will still exist) 3. it handles polymorphism very badly. say you use a CD or a CE in Observation.value. the path for the code will be value/CD/code value/CE/code respectively btw, it doesn't rule about elements vs attributes. We still get to choose about that ;-) I note it provides an ITS level wrapper. This is a concept that I am considering creating for other reasons anyway, some of them the same as the reason XMI has it. does anyone have any experience or any comments with the XMI serialisation? Grahame From Charlie at ramseysystems.co.uk Mon Jul 31 11:46:09 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Mon, 31 Jul 2006 11:46:09 +0100 Subject: [New-ITS] namespace abbreviations Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB83@ramseysc1420.RamseyNet.local> Grahame This is foreign to me too -- I have seen it as style guidance for hand-authored schemas -- and that is reasonable -- but unless there are other interoperability standards that are fixing prefixes in instances I think that we should avoid it. Even if there are we should tread carefully -- HL7v3 fragments will be included with XML fragments from many other namespaces -- and if the habit of fixing namespace prefixes spreads there will be name clashes that cannot be sorted. Thus while we may think that no one else will want the prefix "hl7", it is unreasonable to expect this to be a normal way to process XML fragments - and so may well restrict the use of some tools etc. If we go for more than one namespace (such as a namespace for every model), then we will use up prefixes far faster, and the case against fixed prefixes gets even stronger (as the likelihood of direct clashes increases) All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: new-its-bounces at lists.hl7.org.uk > [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve > Sent: 20 July 2006 06:27 > To: new-its at lists.hl7.org.uk > Subject: [New-ITS] namespace abbreviations > > Would any one like to comment on the idea that the standard > should fix the namespace abbreviations used in the instances? > > Several of the NDR's I have read do this, but it is foreign > to my thinking. > > Grahame > _______________________________________________ > New-ITS mailing list > New-ITS at lists.hl7.org.uk > http://lists.hl7.org.uk/mailman/listinfo/new-its > > From grahame at kestral.com.au Mon Jul 31 11:51:53 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 31 Jul 2006 20:51:53 +1000 Subject: [New-ITS] namespace abbreviations In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FB83@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FB83@ramseysc1420.RamseyNet.local> Message-ID: <44CDE0C9.7050401@kestral.com.au> We certainly want to try not to use multiple name spaces. I think it just means that xslt processing is a lot easier - doesn't xslt have problems with namespaces? how do the existing suppliers xslt interfaces handle this? For the reasons you say, I was surprised to see it done, but these are widely used standards that do it. Grahame Charlie McCay wrote: > Grahame > > This is foreign to me too -- I have seen it as style guidance for > hand-authored schemas -- and that is reasonable -- but unless there are > other interoperability standards that are fixing prefixes in instances I > think that we should avoid it. > > Even if there are we should tread carefully -- HL7v3 fragments will be > included with XML fragments from many other namespaces -- and if the > habit of fixing namespace prefixes spreads there will be name clashes > that cannot be sorted. Thus while we may think that no one else will > want the prefix "hl7", it is unreasonable to expect this to be a normal > way to process XML fragments - and so may well restrict the use of some > tools etc. > > If we go for more than one namespace (such as a namespace for every > model), then we will use up prefixes far faster, and the case against > fixed prefixes gets even stronger (as the likelihood of direct clashes > increases) > > All the best > > Charlie > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > >> -----Original Message----- >> From: new-its-bounces at lists.hl7.org.uk >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve >> Sent: 20 July 2006 06:27 >> To: new-its at lists.hl7.org.uk >> Subject: [New-ITS] namespace abbreviations >> >> Would any one like to comment on the idea that the standard >> should fix the namespace abbreviations used in the instances? >> >> Several of the NDR's I have read do this, but it is foreign >> to my thinking. >> >> Grahame >> _______________________________________________ >> New-ITS mailing list >> New-ITS at lists.hl7.org.uk >> http://lists.hl7.org.uk/mailman/listinfo/new-its >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From Charlie at ramseysystems.co.uk Mon Jul 31 12:07:44 2006 From: Charlie at ramseysystems.co.uk (Charlie McCay) Date: Mon, 31 Jul 2006 12:07:44 +0100 Subject: [New-ITS] namespace abbreviations Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A04FB84@ramseysc1420.RamseyNet.local> Grahame Using multiple namespaces is a pain in XSLT if the same structure exists in different namespaces -- thus if structures derived from a common model all were in different namespaces then writing namespace-agnostic templates to do common processing is not nice. Same goes (only more so) for using namespaces to manage versions -- stylesheets written to use one namespace would need to be changed to work with another. Early versions of the HL7v3 XML ITS used a different namespace for each messagetype - which made for clean type names but ugly instances and made code reuse (certainly in XSLT) more difficult. I agree that we should avoid using more than one namespace. Fixing the prefix would not make much difference to XSLT -- the prefixes in the templates do not need to be the same as the prefixes in the instance, the XSLT processor dereferences them and uses the namespace URI for matching. One can set the prefix to be used for a namespace in XSLT output, so that is ok too. However other tools may not be so flexible -- and the name clash issue remains. There was an argument in the past that it was worth fixing prefixes because it made DTD validation possible -- that may be why it has got into some standards. There has been no demand for DTD support in the HL7 community for a while I agree that it would be interesting to get supplier views on this All the best Charlie Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel 01743 232278 / 07808 570172 skype: charliemccay > -----Original Message----- > From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of > Grahame Grieve > Sent: 31 July 2006 11:52 > To: Charlie McCay > Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk > Subject: Re: [New-ITS] namespace abbreviations > > > We certainly want to try not to use multiple name spaces. > > I think it just means that xslt processing is a lot easier - > doesn't xslt have problems with namespaces? > how do the existing suppliers xslt interfaces handle this? > > For the reasons you say, I was surprised to see it done, but > these are widely used standards that do it. > > Grahame > > > Charlie McCay wrote: > > Grahame > > > > This is foreign to me too -- I have seen it as style guidance for > > hand-authored schemas -- and that is reasonable -- but unless there > > are other interoperability standards that are fixing prefixes in > > instances I think that we should avoid it. > > > > Even if there are we should tread carefully -- HL7v3 > fragments will be > > included with XML fragments from many other namespaces -- > and if the > > habit of fixing namespace prefixes spreads there will be > name clashes > > that cannot be sorted. Thus while we may think that no one > else will > > want the prefix "hl7", it is unreasonable to expect this to be a > > normal way to process XML fragments - and so may well > restrict the use > > of some tools etc. > > > > If we go for more than one namespace (such as a namespace for every > > model), then we will use up prefixes far faster, and the > case against > > fixed prefixes gets even stronger (as the likelihood of > direct clashes > > increases) > > > > All the best > > > > Charlie > > > > > > > > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > > Dogpole, Shrewsbury, Shropshire SY1 1ES > > > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > > > > > > >> -----Original Message----- > >> From: new-its-bounces at lists.hl7.org.uk > >> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of > Grahame Grieve > >> Sent: 20 July 2006 06:27 > >> To: new-its at lists.hl7.org.uk > >> Subject: [New-ITS] namespace abbreviations > >> > >> Would any one like to comment on the idea that the standard should > >> fix the namespace abbreviations used in the instances? > >> > >> Several of the NDR's I have read do this, but it is foreign to my > >> thinking. > >> > >> Grahame > >> _______________________________________________ > >> New-ITS mailing list > >> New-ITS at lists.hl7.org.uk > >> http://lists.hl7.org.uk/mailman/listinfo/new-its > >> > >> > > > > -- > Grahame Grieve > CTO, Jiva Medical Software Integration Tools > CTO, Kestral Computing Healthcare Applications > > From grahame at kestral.com.au Mon Jul 31 12:15:40 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 31 Jul 2006 21:15:40 +1000 Subject: [New-ITS] namespace abbreviations In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A04FB84@ramseysc1420.RamseyNet.local> References: <7A55F2E13F53E749A4C13A8E53B7424A04FB84@ramseysc1420.RamseyNet.local> Message-ID: <44CDE65C.6080409@kestral.com.au> well, there's some suppliers / xml people on this list. I will assume that fixing the namespace prefix is a historical left over from early xml days, and not relevant in today's standards. unless we hear otherwise.... Grahame Charlie McCay wrote: > Grahame > > Using multiple namespaces is a pain in XSLT if the same structure exists > in different namespaces -- thus if structures derived from a common > model all were in different namespaces then writing namespace-agnostic > templates to do common processing is not nice. Same goes (only more so) > for using namespaces to manage versions -- stylesheets written to use > one namespace would need to be changed to work with another. > > Early versions of the HL7v3 XML ITS used a different namespace for each > messagetype - which made for clean type names but ugly instances and > made code reuse (certainly in XSLT) more difficult. > > I agree that we should avoid using more than one namespace. > > > Fixing the prefix would not make much difference to XSLT -- the prefixes > in the templates do not need to be the same as the prefixes in the > instance, the XSLT processor dereferences them and uses the namespace > URI for matching. One can set the prefix to be used for a namespace in > XSLT output, so that is ok too. However other tools may not be so > flexible -- and the name clash issue remains. > > There was an argument in the past that it was worth fixing prefixes > because it made DTD validation possible -- that may be why it has got > into some standards. There has been no demand for DTD support in the > HL7 community for a while > > I agree that it would be interesting to get supplier views on this > > All the best > > Charlie > > > Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D > Dogpole, Shrewsbury, Shropshire SY1 1ES > > tel 01743 232278 / 07808 570172 skype: charliemccay > > > > >> -----Original Message----- >> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of >> Grahame Grieve >> Sent: 31 July 2006 11:52 >> To: Charlie McCay >> Cc: grahame at jivamedical.com; new-its at lists.hl7.org.uk >> Subject: Re: [New-ITS] namespace abbreviations >> >> >> We certainly want to try not to use multiple name spaces. >> >> I think it just means that xslt processing is a lot easier - >> doesn't xslt have problems with namespaces? >> how do the existing suppliers xslt interfaces handle this? >> >> For the reasons you say, I was surprised to see it done, but >> these are widely used standards that do it. >> >> Grahame >> >> >> Charlie McCay wrote: >>> Grahame >>> >>> This is foreign to me too -- I have seen it as style guidance for >>> hand-authored schemas -- and that is reasonable -- but unless there >>> are other interoperability standards that are fixing prefixes in >>> instances I think that we should avoid it. >>> >>> Even if there are we should tread carefully -- HL7v3 >> fragments will be >>> included with XML fragments from many other namespaces -- >> and if the >>> habit of fixing namespace prefixes spreads there will be >> name clashes >>> that cannot be sorted. Thus while we may think that no one >> else will >>> want the prefix "hl7", it is unreasonable to expect this to be a >>> normal way to process XML fragments - and so may well >> restrict the use >>> of some tools etc. >>> >>> If we go for more than one namespace (such as a namespace for every >>> model), then we will use up prefixes far faster, and the >> case against >>> fixed prefixes gets even stronger (as the likelihood of >> direct clashes >>> increases) >>> >>> All the best >>> >>> Charlie >>> >>> >>> >>> >>> Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D >>> Dogpole, Shrewsbury, Shropshire SY1 1ES >>> >>> tel 01743 232278 / 07808 570172 skype: charliemccay >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: new-its-bounces at lists.hl7.org.uk >>>> [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of >> Grahame Grieve >>>> Sent: 20 July 2006 06:27 >>>> To: new-its at lists.hl7.org.uk >>>> Subject: [New-ITS] namespace abbreviations >>>> >>>> Would any one like to comment on the idea that the standard should >>>> fix the namespace abbreviations used in the instances? >>>> >>>> Several of the NDR's I have read do this, but it is foreign to my >>>> thinking. >>>> >>>> Grahame >>>> _______________________________________________ >>>> New-ITS mailing list >>>> New-ITS at lists.hl7.org.uk >>>> http://lists.hl7.org.uk/mailman/listinfo/new-its >>>> >>>> >> -- >> Grahame Grieve >> CTO, Jiva Medical Software Integration Tools >> CTO, Kestral Computing Healthcare Applications >> >> > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications From grahame at kestral.com.au Mon Jul 31 12:29:55 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Mon, 31 Jul 2006 21:29:55 +1000 Subject: [New-ITS] Data Types Message-ID: <44CDE9B3.9070909@kestral.com.au> Attached is a draft version of the Implementable Model for Data types. Other implementable models will build on this package. This package may grow into more than just data types. in particular, I expect it will acquire more structural vocabulary items as enumerations. So it may end up not being called the data types. There is a number of files in this package: + Datatypes.doc - document presentation + datatypes.eap - enterprise architecture source for the UML diagrams + datatypes.ocl - an internal UML representation I use to compile check the OCL statements. The schemas are generated from this source. + datatypes.xsd - a generated schema where everything is elements. Includes a single example schematron + datatypes-attributes.xsd - a generated schema where OCL Primitives are XML attributes. Includes a single example schematron When we pick between elements and attributes, then I will fill out the schematron assertions. I expect to have a matching schematron assertion for every OCL constraint, though some of them will be fairly difficult. Schematron experts: is there a way to do defines like the OCL does? Relax NG experts: I imagine it will also be easy to code generate a Relax NG schema - if someone lays out the general shape of it for ANY, QTY, TS, SET and IVL I could code generate that too. comments are very welcome. Things you might want to check: * current state of play in nullFlavors - I am still thinking about how to rationalise them further. * how ED works - no inline XML in this model. * how GTS works - I don't know whether I've made things more difficult or not.... Grahame -------------- next part -------------- A non-text attachment was scrubbed... Name: UML ITS Data Types.zip Type: application/x-zip-compressed Size: 520111 bytes Desc: not available Url : http://lists.hl7.org.uk/pipermail/new-its/attachments/20060731/13da6675/UMLITSDataTypes-0001.bin From Laura.Sato at cfh.nhs.uk Mon Jul 31 15:07:48 2006 From: Laura.Sato at cfh.nhs.uk (Sato Laura) Date: Mon, 31 Jul 2006 15:07:48 +0100 Subject: [New-ITS] XMI Message-ID: <1A3D105C334EAE49BDDD93D8767573F504104C76@EXCHAQ2.nhsia.nhs.uk> Why are delta updates a weakness? Best regards, Laura -----Original Message----- From: new-its-bounces at lists.hl7.org.uk [mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of Grahame Grieve Sent: 30 July 2006 14:52 To: new-its at lists.hl7.org.uk Subject: [New-ITS] XMI I have been looking at the XMI serialisation. We could use it in the UML ITS, as the way that we specify how the XML reflects the UML diagrams. It has many strengths: 1. it's a standard (OMG no less), so tooling would exist 2. it allows you to do schemas (by all styles) and it lets you do DTDs (our current approach and the one I was going to propose do not allow anything but venetion blind schemas) 3. it is very name centric 4. it's very solid and proven 5. it has inbuilt support for id/idref resting on good standards under good control from the diagrams. 6. it allows all sorts of clever things like delta updates. it has some very strong weaknesses: 1. it allows all sorts of clever things like delta updates. 2. it is far more verbose than what I was going to propose or even the existing XML ITS (though the structural advantages we are pursuing will still exist) 3. it handles polymorphism very badly. say you use a CD or a CE in Observation.value. the path for the code will be value/CD/code value/CE/code respectively btw, it doesn't rule about elements vs attributes. We still get to choose about that ;-) I note it provides an ITS level wrapper. This is a concept that I am considering creating for other reasons anyway, some of them the same as the reason XMI has it. does anyone have any experience or any comments with the XMI serialisation? Grahame _______________________________________________ New-ITS mailing list New-ITS at lists.hl7.org.uk http://lists.hl7.org.uk/mailman/listinfo/new-its This e-mail is confidential and privileged. If you are not the intended recipient please accept our apologies; please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. From grahame at kestral.com.au Mon Jul 31 18:51:25 2006 From: grahame at kestral.com.au (Grahame Grieve) Date: Tue, 01 Aug 2006 03:51:25 +1000 Subject: [New-ITS] XMI In-Reply-To: <1A3D105C334EAE49BDDD93D8767573F504104C76@EXCHAQ2.nhsia.nhs.uk> References: <1A3D105C334EAE49BDDD93D8767573F504104C76@EXCHAQ2.nhsia.nhs.uk> Message-ID: <44CE431D.8080906@kestral.com.au> > Why are delta updates a weakness? it's certainly complicating in lot's of ways. it would be hard to deal with a delta, let alone figure out how it interacts with the Hl7 dynamic model Grahame