From grahame at kestral.com.au Tue Nov 14 22:27:46 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Wed, 15 Nov 2006 09:27:46 +1100
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A0A2A6A@ramseysc1420.RamseyNet.local>
References: <7A55F2E13F53E749A4C13A8E53B7424A0A2A6A@ramseysc1420.RamseyNet.local>
Message-ID: <455A42E2.4060606@kestral.com.au>
> Comments on ED -- I'm not happy with it always being base64
> encoded
why? - please outline what the functional problems with this are
> Also if you are touching the schema, it would be useful to have some
> version information in it as appinfo or even just as comment.
good point
>>> ED.data
>>>
>>> At the moment ed.data is type base64Binary, should this be of type
>>> xsd:any to allow for blocks of XML?
>> I don't think it should contain blocks of XML. I'll say why:
>
> The reasons better be good because this truly is the first time I have
> *EVER* heard it suggested that Dsig blocks should be base64 encodede or
> escaped befor being included in an XML document, and this really does
> seem an odd thing to go off-piste with.
well, I can see that you don't feel strongly about this ;-)
(and I'm glad to finally get some pushback on this issue)
firstly, I've said nothing about DSig. Why do you link this?
If we've asserted anywhere that DSIG and ED are somehow linked,
then we've made a mistake, and confused abstract and ITS layers
somewhere.
>> * there's no UML way to describe this
>
> Modeller theology -- and I do not believe it -- it is whether the
> UML-XML mapping algorithm supports it that matters -- and that is not
> fixed in stone the way UML is
so, what would you propose?
>
>> * because it's an odd concept - rendering multiple conceptual
>> layers in a single XML document
>
> There is no reason for changing the syntax just because you are
> defineing the sematics in a different way -- this is modeller navel
> gazing getting in the way of what is simple and useful for implemennters
actually, while you might call it modeller navel gazing I ran into this
in a very painful way when implementing web services. How's a toolkit
supposed to deal with this?
In fact, the semantics are this: here's some data, we don't know anything
about it, it's not part of our model, it's just stuff. So the XML
should treat it exactly the same - it's just stuff, and make it
base64binary.
Grahame
From Thomas.Beale at OceanInformatics.biz Sat Nov 18 22:10:13 2006
From: Thomas.Beale at OceanInformatics.biz (Thomas Beale)
Date: Sun, 19 Nov 2006 08:10:13 +1000
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <455A42E2.4060606@kestral.com.au>
References: <7A55F2E13F53E749A4C13A8E53B7424A0A2A6A@ramseysc1420.RamseyNet.local>
<455A42E2.4060606@kestral.com.au>
Message-ID: <455F84C5.4060900@OceanInformatics.biz>
Grahame Grieve wrote:
>
> In fact, the semantics are this: here's some data, we don't know anything
> about it, it's not part of our model, it's just stuff. So the XML
> should treat it exactly the same - it's just stuff, and make it
> base64binary.
>
for what it's worth, this is exactly the thinking in openEHR for this
data type. Making it inline XML has no value as far as we can see, and
poses risks. But in openEHR there is also a data type DV_PARSABLE which
could be used to accommodate inline text of any kind, including XML.
However, it is really intended for things like small UCUM unit strings
and such.
- thomas beale
From Charlie at ramseysystems.co.uk Mon Nov 20 13:58:16 2006
From: Charlie at ramseysystems.co.uk (Charlie McCay)
Date: Mon, 20 Nov 2006 13:58:16 -0000
Subject: [New-ITS] UML datatypes issues
Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A0A2AA2@ramseysc1420.RamseyNet.local>
Thomas
I cannot find the email that this is in response to - so at risk of
duplication:
This discussion went on in HL7 -- with some saying the contents of ED is
"stuff" and since it is not hl7 stuff, it can all be packaged in one way
(base64) to keep it out of the way of the stuff that we do define.
However - many implementers do not care who defines the content, and
whether it comes from the domain model (be it HL7 or openEHR) or some
other content model (DICOM / W3C-Dsig / XHTML / ...). If it is not well
formed XML clearly it must be escaped or encoded in some way -- if it is
in XML already then additionally encoding/decoding it as base64 is
adding a processing step that adds no value to the implementation and is
a somewhat concrete realisation of a boundary that is relevant only to
modellers. This is experienced as a frustrating speed ramp / stumbling
block by those doing implementations.
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 Thomas Beale
> Sent: 18 November 2006 22:10
> To: new-its at lists.hl7.org.uk
> Subject: Re: [New-ITS] UML datatypes issues
>
> Grahame Grieve wrote:
> >
> > In fact, the semantics are this: here's some data, we don't know
> > anything about it, it's not part of our model, it's just
> stuff. So the
> > XML should treat it exactly the same - it's just stuff, and make it
> > base64binary.
> >
> for what it's worth, this is exactly the thinking in openEHR
> for this data type. Making it inline XML has no value as far
> as we can see, and poses risks. But in openEHR there is also
> a data type DV_PARSABLE which could be used to accommodate
> inline text of any kind, including XML.
> However, it is really intended for things like small UCUM
> unit strings and such.
>
> - thomas beale
>
>
> _______________________________________________
> New-ITS mailing list
> New-ITS at lists.hl7.org.uk
> http://lists.hl7.org.uk/mailman/listinfo/new-its
>
>
From thomas at deepthought.com.au Tue Nov 21 02:53:05 2006
From: thomas at deepthought.com.au (Thomas Beale)
Date: Tue, 21 Nov 2006 12:53:05 +1000
Subject: [New-ITS] UML datatypes issues
Message-ID: <20061121025305.5378.qmail@bne005wm.server-mail.com>
Hi Charlie,
> Thomas
>
> I cannot find the email that this is in response to - so at risk of
> duplication:
>
> This discussion went on in HL7 -- with some saying the contents of ED is
> "stuff" and since it is not hl7 stuff, it can all be packaged in one way
> (base64) to keep it out of the way of the stuff that we do define.
>
> However - many implementers do not care who defines the content, and
> whether it comes from the domain model (be it HL7 or openEHR) or some
> other content model (DICOM / W3C-Dsig / XHTML / ...).
well....which implementers are we talking about here? If they are implementers
of HL7v3 then that's what they care about; they will hand off EDs to other tools
to interpret, according to the MIME type found in the ED.
> If it is not well
> formed XML clearly it must be escaped or encoded in some way -- if it is
> in XML already then additionally encoding/decoding it as base64 is
> adding a processing step that adds no value to the implementation and is
> a somewhat concrete realisation of a boundary that is relevant only to
> modellers.
I don't understand what "only relevant to modellers" means - it's relevant to
anyone as far as I can see.
> This is experienced as a frustrating speed ramp / stumbling
> block by those doing implementations.
a) I can't believe this makes any performance difference at all, unless we are
talking many Mb
b) if the ED content is left in its raw XML form, it will get processed by the first
level of software (DOM or whatever other kind of XML parser is being used),
when in fact this probably isn't necessary, since the content is most likely to be
handed off to another app or tool containing its own parser - so in fact, we
could easily be duplicating XML processing unnecessarily. In a small message
containing a largish ED, this could completely change the processing cost per
message, since the ED lump might often not be processed at all - except on
demand later by a doc reading email (it all depends on what is done with the
ED). Processing it in the message switch seems unlikely to be useful to me in
general (even if there are specific cases where it is useful).
c) any errors in the ED XML lump if left in raw form and processed as per b)
will kill processing of the message needlessly
d) there may well be different security level associated with the ED (e.g. it might
be a Word doc of a letter); this would mean it has to be encrypted, signed and
base64 converted anyway...
e) I don't see why base64 encoding is a specific stumbling block for develpers -
only as much as any other encoding of data is.
Please take the above as devil's advocate arguments - I have not studied the
evidence yet!
- thomas
>
> 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 Thomas Beale
> > Sent: 18 November 2006 22:10
> > To: new-its at lists.hl7.org.uk
> > Subject: Re: [New-ITS] UML datatypes issues
> >
> > Grahame Grieve wrote:
> > >
> > > In fact, the semantics are this: here's some data, we don't know
> > > anything about it, it's not part of our model, it's just
> > stuff. So the
> > > XML should treat it exactly the same - it's just stuff, and make it
> > > base64binary.
> > >
> > for what it's worth, this is exactly the thinking in openEHR
> > for this data type. Making it inline XML has no value as far
> > as we can see, and poses risks. But in openEHR there is also
> > a data type DV_PARSABLE which could be used to accommodate
> > inline text of any kind, including XML.
> > However, it is really intended for things like small UCUM
> > unit strings and such.
> >
> > - thomas beale
> >
> >
> > _______________________________________________
> > New-ITS mailing list
> > New-ITS at lists.hl7.org.uk
> > http://lists.hl7.org.uk/mailman/listinfo/new-its
> >
> >
--
Ocean Informatics: http://www.OceanInformatics.biz
openEHR: http://www.openEHR.org
From grahame at kestral.com.au Tue Nov 21 03:08:19 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Tue, 21 Nov 2006 14:08:19 +1100
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <20061121025305.5378.qmail@bne005wm.server-mail.com>
References: <20061121025305.5378.qmail@bne005wm.server-mail.com>
Message-ID: <45626DA3.1060000@kestral.com.au>
It seems the fundamental question is whether ED is good modelling
or not. If content is put into ED so it doesn't have to be modelled,
but it's important, then this would mean that boundary was only
relevant to modelers and they were not relevant to implementers...
I'd rather not think of things this way.
If the model says that the content is "encapsulated data",
then the XML should treat it like that, because that's
appropriate (echoing Tom's other comments)
Grahame
Thomas Beale wrote:
>
> Hi Charlie,
>
>> Thomas
>>
>> I cannot find the email that this is in response to - so at risk of
>> duplication:
>>
>> This discussion went on in HL7 -- with some saying the contents of ED is
>> "stuff" and since it is not hl7 stuff, it can all be packaged in one way
>> (base64) to keep it out of the way of the stuff that we do define.
>>
>> However - many implementers do not care who defines the content, and
>> whether it comes from the domain model (be it HL7 or openEHR) or some
>> other content model (DICOM / W3C-Dsig / XHTML / ...).
>
> well....which implementers are we talking about here? If they are implementers
> of HL7v3 then that's what they care about; they will hand off EDs to other tools
> to interpret, according to the MIME type found in the ED.
>
>> If it is not well
>> formed XML clearly it must be escaped or encoded in some way -- if it is
>> in XML already then additionally encoding/decoding it as base64 is
>> adding a processing step that adds no value to the implementation and is
>> a somewhat concrete realisation of a boundary that is relevant only to
>> modellers.
>
> I don't understand what "only relevant to modellers" means - it's relevant to
> anyone as far as I can see.
>
>> This is experienced as a frustrating speed ramp / stumbling
>> block by those doing implementations.
>
> a) I can't believe this makes any performance difference at all, unless we are
> talking many Mb
>
> b) if the ED content is left in its raw XML form, it will get processed by the first
> level of software (DOM or whatever other kind of XML parser is being used),
> when in fact this probably isn't necessary, since the content is most likely to be
> handed off to another app or tool containing its own parser - so in fact, we
> could easily be duplicating XML processing unnecessarily. In a small message
> containing a largish ED, this could completely change the processing cost per
> message, since the ED lump might often not be processed at all - except on
> demand later by a doc reading email (it all depends on what is done with the
> ED). Processing it in the message switch seems unlikely to be useful to me in
> general (even if there are specific cases where it is useful).
>
> c) any errors in the ED XML lump if left in raw form and processed as per b)
> will kill processing of the message needlessly
>
> d) there may well be different security level associated with the ED (e.g. it might
> be a Word doc of a letter); this would mean it has to be encrypted, signed and
> base64 converted anyway...
>
> e) I don't see why base64 encoding is a specific stumbling block for develpers -
> only as much as any other encoding of data is.
>
> Please take the above as devil's advocate arguments - I have not studied the
> evidence yet!
>
> - thomas
>
>
>
>> 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 Thomas Beale
>>> Sent: 18 November 2006 22:10
>>> To: new-its at lists.hl7.org.uk
>>> Subject: Re: [New-ITS] UML datatypes issues
>>>
>>> Grahame Grieve wrote:
>>>> In fact, the semantics are this: here's some data, we don't know
>>>> anything about it, it's not part of our model, it's just
>>> stuff. So the
>>>> XML should treat it exactly the same - it's just stuff, and make it
>>>> base64binary.
>>>>
>>> for what it's worth, this is exactly the thinking in openEHR
>>> for this data type. Making it inline XML has no value as far
>>> as we can see, and poses risks. But in openEHR there is also
>>> a data type DV_PARSABLE which could be used to accommodate
>>> inline text of any kind, including XML.
>>> However, it is really intended for things like small UCUM
>>> unit strings and such.
>>>
>>> - thomas beale
>>>
>>>
>>> _______________________________________________
>>> 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 Wed Nov 22 17:24:26 2006
From: ann.wrightson at bt.com (ann.wrightson@bt.com)
Date: Wed, 22 Nov 2006 17:24:26 -0000
Subject: [New-ITS] UML datatypes issues
Message-ID: <849288029444F74899F8C8E3D479FF6D01B9ED72@E03MVZ3-UKDY.domain1.systemhost.net>
>If the model says that the content is "encapsulated data", then the XML
>should treat it like that, because that's appropriate
It depends how you link the concepts of "encapsulation" in the model,
and "encapsulation" in the XML. IMO these are not synonymous, this is a
concept-mapping decision (conscious or unconscious), and from where I
stand, mapping model-encapsulation to XML-subtree is a pretty normal
thing for content that is (or rather if it were a standalone XML
document would be) well-formed XML.
My answer to Thomas's "who is this 'anyone'?" question is that I believe
it means people who are not HL7 specialists but are experienced with XML
messaging. In this world, layers of containment in XML are normal, with
message envelopes etc, and to convert the contents of such an envelope
to base-64 just because it is at a different semantic level for
processing is, from that viewpoint, rather perverse.
Tactical use of "any" content models in layered schemas is the usual way
of avoiding validation overhead. Vulnerability to payload XML faults,
and parsing costs of handling large XML payloads at architectural nodes
such as reliable-forwarders that don't care about the payload, are of
course a normal part of the landscape...
Ann W.
Ann Wrightson | MIM Comments Co-ordinator | Integration | NHS Spine
Systems Engineering | Global Health and Government Practice | BT Global
Services | Tel: +44 (0)113 306 5103 | Mob: +44 (0)7903 161678 | E:
ann.wrightson at bt.com | W: www.bt.com/globalservices |
-----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, November 21, 2006 3:08 AM
To: Thomas.Beale at OceanInformatics.biz
Cc: new-its at lists.hl7.org.uk; Charlie McCay
Subject: Re: [New-ITS] UML datatypes issues
It seems the fundamental question is whether ED is good modelling or
not. If content is put into ED so it doesn't have to be modelled, but
it's important, then this would mean that boundary was only relevant to
modelers and they were not relevant to implementers...
I'd rather not think of things this way.
Grahame
Thomas Beale wrote:
>
> Hi Charlie,
>
>> Thomas
>>
>> I cannot find the email that this is in response to - so at risk of
>> duplication:
>>
>> This discussion went on in HL7 -- with some saying the contents of ED
>> is "stuff" and since it is not hl7 stuff, it can all be packaged in
>> one way
>> (base64) to keep it out of the way of the stuff that we do define.
>>
>> However - many implementers do not care who defines the content, and
>> whether it comes from the domain model (be it HL7 or openEHR) or some
>> other content model (DICOM / W3C-Dsig / XHTML / ...).
>
> well....which implementers are we talking about here? If they are
> implementers of HL7v3 then that's what they care about; they will hand
> off EDs to other tools to interpret, according to the MIME type found
in the ED.
>
>> If it is not well
>> formed XML clearly it must be escaped or encoded in some way -- if it
>> is in XML already then additionally encoding/decoding it as base64 is
>> adding a processing step that adds no value to the implementation and
>> is a somewhat concrete realisation of a boundary that is relevant
>> only to modellers.
>
> I don't understand what "only relevant to modellers" means - it's
> relevant to anyone as far as I can see.
>
>> This is experienced as a frustrating speed ramp / stumbling
>> block by those doing implementations.
>
> a) I can't believe this makes any performance difference at all,
> unless we are talking many Mb
>
> b) if the ED content is left in its raw XML form, it will get
> processed by the first level of software (DOM or whatever other kind
> of XML parser is being used), when in fact this probably isn't
> necessary, since the content is most likely to be handed off to
> another app or tool containing its own parser - so in fact, we could
> easily be duplicating XML processing unnecessarily. In a small message
> containing a largish ED, this could completely change the processing
> cost per message, since the ED lump might often not be processed at
> all - except on demand later by a doc reading email (it all depends on
> what is done with the ED). Processing it in the message switch seems
unlikely to be useful to me in general (even if there are specific cases
where it is useful).
>
> c) any errors in the ED XML lump if left in raw form and processed as
> per b) will kill processing of the message needlessly
>
> d) there may well be different security level associated with the ED
> (e.g. it might be a Word doc of a letter); this would mean it has to
> be encrypted, signed and
> base64 converted anyway...
>
> e) I don't see why base64 encoding is a specific stumbling block for
> develpers - only as much as any other encoding of data is.
>
> Please take the above as devil's advocate arguments - I have not
> studied the evidence yet!
>
> - thomas
>
>
>
>> 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 Thomas Beale
>>> Sent: 18 November 2006 22:10
>>> To: new-its at lists.hl7.org.uk
>>> Subject: Re: [New-ITS] UML datatypes issues
>>>
>>> Grahame Grieve wrote:
>>>> In fact, the semantics are this: here's some data, we don't know
>>>> anything about it, it's not part of our model, it's just
>>> stuff. So the
>>>> XML should treat it exactly the same - it's just stuff, and make it
>>>> base64binary.
>>>>
>>> for what it's worth, this is exactly the thinking in openEHR for
>>> this data type. Making it inline XML has no value as far as we can
>>> see, and poses risks. But in openEHR there is also a data type
>>> DV_PARSABLE which could be used to accommodate inline text of any
>>> kind, including XML.
>>> However, it is really intended for things like small UCUM unit
>>> strings and such.
>>>
>>> - thomas beale
>>>
>>>
>>> _______________________________________________
>>> 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 Nov 22 19:27:58 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Thu, 23 Nov 2006 06:27:58 +1100
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <849288029444F74899F8C8E3D479FF6D01B9ED72@E03MVZ3-UKDY.domain1.systemhost.net>
References: <849288029444F74899F8C8E3D479FF6D01B9ED72@E03MVZ3-UKDY.domain1.systemhost.net>
Message-ID: <4564A4BE.30505@kestral.com.au>
ann.wrightson at bt.com wrote:
>> If the model says that the content is "encapsulated data", then the XML
>
>> should treat it like that, because that's appropriate
>
> It depends how you link the concepts of "encapsulation" in the model,
> and "encapsulation" in the XML. IMO these are not synonymous, this is a
> concept-mapping decision (conscious or unconscious), and from where I
> stand, mapping model-encapsulation to XML-subtree is a pretty normal
> thing for content that is (or rather if it were a standalone XML
> document would be) well-formed XML.
so, you wouldn't want a choice here? it would actually be worse to a
allow either xml or base64 content? but since base64 has to be allowed
for non-xml content, how do you stop the use of it for XML content?
I do see this as an xml-centric vs model-centric development issue.
Grahame
From grahame at kestral.com.au Thu Nov 23 06:09:14 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Thu, 23 Nov 2006 17:09:14 +1100
Subject: [New-ITS] IVL
Message-ID: <45653B0A.8080007@kestral.com.au>
I am thinking of changing IVL in the UML ITS so it's not a generic.
This will allow me to be very much more specific about
things - for the implementors.
I would define an IVL_PQ, IVL_MO, IVL_REAL, IVL_INT
and IVL_TS
I do not know of any use case where the fact that
all these things are IVL's is relevant and might
be treated with the same code, whereas I know that
it would be nice to do things like this:
and really importantly:
so the schema for these would be:
and
There would be appropriate schematrons for the co-variants.
I just can't be that nimble if IVL is a generic, and
we're trying to be formal about things so implementers
can work in lots of tools and see the same things and
have them work well.
If you compare these with what I've got in the current schema
(appended) you'll see that these are far more elegant for
implementors. I've spent a couple of hours playing with
possibilities for improving the ones below in the context of the
UML ITS, and I just can't do it without inventing all sorts
of magic rules - which break some implementation path or other.
So I propose not having the generic IVL. This moves all the
magic into the XUM production, which is an ok place to have
magic.
comments?
Grahame
From ann.wrightson at bt.com Thu Nov 23 08:46:28 2006
From: ann.wrightson at bt.com (ann.wrightson@bt.com)
Date: Thu, 23 Nov 2006 08:46:28 -0000
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <4564A4BE.30505@kestral.com.au>
Message-ID: <849288029444F74899F8C8E3D479FF6D01C009FC@E03MVZ3-UKDY.domain1.systemhost.net>
>since base64 has to be allowed for non-xml content, how do you stop the
use of it for XML content?
I'm usually of the "optionality considered harmful" school of thought
for standards, but in this case we should see allowing both in principle
as a positive and helpful way of dealing with the diversity of
model-encapsulated content, because for any situation it's a trade-off
between various factors such as:
- how likely is it that the XML payload would be broken
- which architectural nodes need to parse it, and when
- which architectural nodes need to validate it, and when
- if these answers are different for different message classes, then
what's the trade-off between the benefits of doing different things for
different classes, & of having just one mechanism.
However, I would not advocate an open free-for-all in implementation,
rather I would recommend that any implementation profile for a
particular community and purpose (such as NHS NPfIT, or like IHE do)
allows one or the other only.
Ann W.
-----Original Message-----
From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of Grahame
Grieve
Sent: Wednesday, November 22, 2006 7:28 PM
To: Wrightson,A,Ann,JPGA8Y C
Cc: new-its at lists.hl7.org.uk
Subject: Re: [New-ITS] UML datatypes issues
ann.wrightson at bt.com wrote:
>> If the model says that the content is "encapsulated data", then the
>> XML
>
>> should treat it like that, because that's appropriate
>
> It depends how you link the concepts of "encapsulation" in the model,
> and "encapsulation" in the XML. IMO these are not synonymous, this is
> a concept-mapping decision (conscious or unconscious), and from where
> I stand, mapping model-encapsulation to XML-subtree is a pretty normal
> thing for content that is (or rather if it were a standalone XML
> document would be) well-formed XML.
so, you wouldn't want a choice here? it would actually be worse to a
allow either xml or base64 content? but since base64 has to be allowed
for non-xml content, how do you stop the use of it for XML content?
I do see this as an xml-centric vs model-centric development issue.
Grahame
From Charlie at ramseysystems.co.uk Thu Nov 23 11:26:25 2006
From: Charlie at ramseysystems.co.uk (Charlie McCay)
Date: Thu, 23 Nov 2006 11:26:25 -0000
Subject: [New-ITS] UML datatypes issues
Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A0A2AC6@ramseysc1420.RamseyNet.local>
Both
I would support Ann's position -- and go a little further -- that there
are some content types where it would be sensible to agree universal
best practice, and some guidelines to help profile editors:
We tried to get started on this with the attachments work, and I think
that this thread resurfaces the need for that work to move forwards.
My personal take is that if the ED is large and does not need to be
processed/validated at the same time as the message then it probably
should be sent as a separate MIME part rather than as base64 in the
message.
In modelling terms this is cleaner because the application ack is saying
that the reference is well formed, but the status of the ED data is
unknown -- as is the case.
To muddy the water a bit here is an issue from the attachments work:
Whether there is a use case for message.attachmentText for carrying ED
data in the transport wrapper rather than inline in the payload is up
for grabs. This would have it in the XML, but in a place where
streaming applications will be able to process it last. Given that this
would only be done if the expectation was that there was a benefit in
separating the processing of the attachment and the payload, if there is
a use for it, the balance of benefit between native XML and base64
encoded XML may be different.
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
> ann.wrightson at bt.com
> Sent: 23 November 2006 08:46
> To: grahame at jivamedical.com
> Cc: new-its at lists.hl7.org.uk
> Subject: Re: [New-ITS] UML datatypes issues
>
> >since base64 has to be allowed for non-xml content, how do
> you stop the
> use of it for XML content?
>
> I'm usually of the "optionality considered harmful" school of
> thought for standards, but in this case we should see
> allowing both in principle as a positive and helpful way of
> dealing with the diversity of model-encapsulated content,
> because for any situation it's a trade-off between various
> factors such as:
> - how likely is it that the XML payload would be broken
> - which architectural nodes need to parse it, and when
> - which architectural nodes need to validate it, and when
> - if these answers are different for different message
> classes, then what's the trade-off between the benefits of
> doing different things for different classes, & of having
> just one mechanism.
>
> However, I would not advocate an open free-for-all in
> implementation, rather I would recommend that any
> implementation profile for a particular community and purpose
> (such as NHS NPfIT, or like IHE do) allows one or the other only.
>
>
> Ann W.
>
> -----Original Message-----
> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of
> Grahame Grieve
> Sent: Wednesday, November 22, 2006 7:28 PM
> To: Wrightson,A,Ann,JPGA8Y C
> Cc: new-its at lists.hl7.org.uk
> Subject: Re: [New-ITS] UML datatypes issues
>
> ann.wrightson at bt.com wrote:
> >> If the model says that the content is "encapsulated data",
> then the
> >> XML
> >
> >> should treat it like that, because that's appropriate
> >
> > It depends how you link the concepts of "encapsulation" in
> the model,
> > and "encapsulation" in the XML. IMO these are not
> synonymous, this is
> > a concept-mapping decision (conscious or unconscious), and
> from where
> > I stand, mapping model-encapsulation to XML-subtree is a
> pretty normal
>
> > thing for content that is (or rather if it were a standalone XML
> > document would be) well-formed XML.
>
> so, you wouldn't want a choice here? it would actually be
> worse to a allow either xml or base64 content? but since
> base64 has to be allowed for non-xml content, how do you stop
> the use of it for XML content?
>
> I do see this as an xml-centric vs model-centric development issue.
>
> 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 Thu Nov 23 23:30:13 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Fri, 24 Nov 2006 10:30:13 +1100
Subject: [New-ITS] UML datatypes issues
In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A0A2AC6@ramseysc1420.RamseyNet.local>
References: <7A55F2E13F53E749A4C13A8E53B7424A0A2AC6@ramseysc1420.RamseyNet.local>
Message-ID: <45662F05.5060505@kestral.com.au>
there isn't always a transport wrapper.
even when there is the semantics of ED really see
reference as a unattached reference. references within
the transport package - when there is one - are slightly
different. We've shoe-horned them into the ED.reference,
but I'm not convinced that we want to do that. The
alternative is to start having a profusion of properties.
Right now, following the discussion so far, I have this
model for ED in the UML ITS:
class = Data (ANY)
attributes
value : Binary
xml : XML
charset : Code
langauge : Code
compression : Compression
mediaType : Code
encoding : EncodingType -- default value is RAW
endclass
context Data
inv "no value if null": isNull implies value.oclIsUndefined
inv "no xml if null": isNull implies xml.oclIsUndefined
inv "value xor xml": value.oclIsDefined xor xml.oclIsDefined
class = ED (Data)
attributes
reference : Ref
integrityCheck : Binary
integrityCheckAlgorithm : IntegrityCheckAlgorithm
thumbnail : Data
endclass
context ED
inv "no reference if null": isNull implies reference.oclIsUndefined
inv "no thumbnail if null": isNull implies (thumbnail.oclIsUndefined or thumbnail.isNull)
inv "reference or value": isNotNull implies ((reference.oclIsDefined and reference.isNotNull) or value.oclIsDefined)
inv "thumbnail has value": thumbnail.oclIsDefined and thumbnail.isNotNull implies thumbnail.value.oclIsDefined
(that's my text form of UML, class/attributes/endclass is the standard
box wrapper, (ANY) is the generalisation. XML is an empty class with
the stereotype <>
The schema for this (without schematron yet, but they would match the ocl):
comments on this arrangement are welcome
Grahame
Charlie McCay wrote:
> Both
>
> I would support Ann's position -- and go a little further -- that there
> are some content types where it would be sensible to agree universal
> best practice, and some guidelines to help profile editors:
>
> We tried to get started on this with the attachments work, and I think
> that this thread resurfaces the need for that work to move forwards.
>
> My personal take is that if the ED is large and does not need to be
> processed/validated at the same time as the message then it probably
> should be sent as a separate MIME part rather than as base64 in the
> message.
> In modelling terms this is cleaner because the application ack is saying
> that the reference is well formed, but the status of the ED data is
> unknown -- as is the case.
>
> To muddy the water a bit here is an issue from the attachments work:
> Whether there is a use case for message.attachmentText for carrying ED
> data in the transport wrapper rather than inline in the payload is up
> for grabs. This would have it in the XML, but in a place where
> streaming applications will be able to process it last. Given that this
> would only be done if the expectation was that there was a benefit in
> separating the processing of the attachment and the payload, if there is
> a use for it, the balance of benefit between native XML and base64
> encoded XML may be different.
>
> 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
>> ann.wrightson at bt.com
>> Sent: 23 November 2006 08:46
>> To: grahame at jivamedical.com
>> Cc: new-its at lists.hl7.org.uk
>> Subject: Re: [New-ITS] UML datatypes issues
>>
>>> since base64 has to be allowed for non-xml content, how do
>> you stop the
>> use of it for XML content?
>>
>> I'm usually of the "optionality considered harmful" school of
>> thought for standards, but in this case we should see
>> allowing both in principle as a positive and helpful way of
>> dealing with the diversity of model-encapsulated content,
>> because for any situation it's a trade-off between various
>> factors such as:
>> - how likely is it that the XML payload would be broken
>> - which architectural nodes need to parse it, and when
>> - which architectural nodes need to validate it, and when
>> - if these answers are different for different message
>> classes, then what's the trade-off between the benefits of
>> doing different things for different classes, & of having
>> just one mechanism.
>>
>> However, I would not advocate an open free-for-all in
>> implementation, rather I would recommend that any
>> implementation profile for a particular community and purpose
>> (such as NHS NPfIT, or like IHE do) allows one or the other only.
>>
>>
>> Ann W.
>>
>> -----Original Message-----
>> From: Grahame Grieve [mailto:grahameg at gmail.com] On Behalf Of
>> Grahame Grieve
>> Sent: Wednesday, November 22, 2006 7:28 PM
>> To: Wrightson,A,Ann,JPGA8Y C
>> Cc: new-its at lists.hl7.org.uk
>> Subject: Re: [New-ITS] UML datatypes issues
>>
>> ann.wrightson at bt.com wrote:
>>>> If the model says that the content is "encapsulated data",
>> then the
>>>> XML
>>>> should treat it like that, because that's appropriate
>>> It depends how you link the concepts of "encapsulation" in
>> the model,
>>> and "encapsulation" in the XML. IMO these are not
>> synonymous, this is
>>> a concept-mapping decision (conscious or unconscious), and
>> from where
>>> I stand, mapping model-encapsulation to XML-subtree is a
>> pretty normal
>>
>>> thing for content that is (or rather if it were a standalone XML
>>> document would be) well-formed XML.
>> so, you wouldn't want a choice here? it would actually be
>> worse to a allow either xml or base64 content? but since
>> base64 has to be allowed for non-xml content, how do you stop
>> the use of it for XML content?
>>
>> I do see this as an xml-centric vs model-centric development issue.
>>
>> 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 Nov 27 14:33:49 2006
From: Charlie at ramseysystems.co.uk (Charlie McCay)
Date: Mon, 27 Nov 2006 14:33:49 -0000
Subject: [New-ITS] IVL
Message-ID: <7A55F2E13F53E749A4C13A8E53B7424A0A2AE1@ramseysc1420.RamseyNet.local>
Grahame
Should the magic not be in the abstract datatypes? -- there seems to be
a good case for saying that the abstract constraints on what is a
meaningful and useful interval are different for the different types, so
a single generic does not make sense.
Further, issues such as "What does IVL_RTO_... or IVL_IVL_... mean?" etc
then disappear.
If you are doing custom interval definitions, it is not clear why you
need highClosed and lowClosed on IVL_INT which has discrete values
within the interval.
Not sure whether it will bring us closer to an ISO set of datatypes -
would be interested to hear your views on that
That said -- I like the magic.
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: 23 November 2006 06:09
> To: new-its at lists.hl7.org.uk
> Subject: [New-ITS] IVL
>
> I am thinking of changing IVL in the UML ITS so it's not a generic.
> This will allow me to be very much more specific about things
> - for the implementors.
>
> I would define an IVL_PQ, IVL_MO, IVL_REAL, IVL_INT and IVL_TS
>
> I do not know of any use case where the fact that all these
> things are IVL's is relevant and might be treated with the
> same code, whereas I know that it would be nice to do things
> like this:
>
> xsi:type="IVL_TS" high="20031020" low="20050101"/> xsi:type="IVL_TS" high="20031020" highbounded="false"/> xsi:type="IVL_TS" width="25" units="yr"/>
>
> and really importantly:
>
>
>
> so the schema for these would be:
>
>
>
>
>
>
> use="optional" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
> and
>
>
>
>
>
> use="optional" />
> use="optional" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
> There would be appropriate schematrons for the co-variants.
>
> I just can't be that nimble if IVL is a generic, and we're
> trying to be formal about things so implementers can work in
> lots of tools and see the same things and have them work well.
>
> If you compare these with what I've got in the current schema
> (appended) you'll see that these are far more elegant for
> implementors. I've spent a couple of hours playing with
> possibilities for improving the ones below in the context of
> the UML ITS, and I just can't do it without inventing all
> sorts of magic rules - which break some implementation path or other.
>
> So I propose not having the generic IVL. This moves all the
> magic into the XUM production, which is an ok place to have magic.
>
> comments?
>
> Grahame
>
>
>
>
>
>
>
> maxOccurs="1" />
> maxOccurs="1" />
> maxOccurs="1" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
>
>
>
>
>
> maxOccurs="1" />
> maxOccurs="1" />
> maxOccurs="1" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
>
>
>
> maxOccurs="1" />
> maxOccurs="1" />
> maxOccurs="1" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
>
>
>
> maxOccurs="1" />
> maxOccurs="1" />
> maxOccurs="1" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
>
>
>
>
> maxOccurs="1" />
> maxOccurs="1" />
> maxOccurs="1" />
>
> use="optional" />
> type="xsd:boolean" use="optional" />
> use="optional" />
> type="xsd:boolean" use="optional" />
>
>
>
> _______________________________________________
> 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 Nov 27 20:08:31 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Tue, 28 Nov 2006 07:08:31 +1100
Subject: [New-ITS] IVL
In-Reply-To: <7A55F2E13F53E749A4C13A8E53B7424A0A2AE1@ramseysc1420.RamseyNet.local>
References: <7A55F2E13F53E749A4C13A8E53B7424A0A2AE1@ramseysc1420.RamseyNet.local>
Message-ID: <456B45BF.9080002@kestral.com.au>
Charlie McCay wrote:
> Grahame
>
> Should the magic not be in the abstract datatypes?
perhaps - but that would be an R2 issue.
> If you are doing custom interval definitions, it is not clear why you
> need highClosed and lowClosed on IVL_INT which has discrete values
> within the interval.
yes that's a good point
> Not sure whether it will bring us closer to an ISO set of datatypes -
> would be interested to hear your views on that
I think it would, but would be interested in Tom's comments on the idea
Grahame
From grahame at kestral.com.au Tue Nov 28 11:07:35 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Tue, 28 Nov 2006 22:07:35 +1100
Subject: [New-ITS] new XUM
Message-ID: <456C1877.1090607@kestral.com.au>
hi
I am uploading a new XUM, it will be on uploading.com and
a notification will arrive soon.
this includes a new datatypes model, and XUMs for MIM 4, MIM 5, MIM 6,
and all the September ballot. Since I am working through the HL7 Mifs,
about 1/3 of them fail with some error or other. I am still whittling
away on the error list.
I have one change I'd like to make to the XUM, which is to make templateId
an attribute. I will get to this soon.
Grahame
From grahame at kestral.com.au Tue Nov 28 19:22:33 2006
From: grahame at kestral.com.au (Grahame Grieve)
Date: Wed, 29 Nov 2006 06:22:33 +1100
Subject: [New-ITS] new XUM
In-Reply-To: <418B502A3861E242AFDED453F3D5B89C10F12F34@i2km99-ukbr.domain1.systemhost.net>
References: <418B502A3861E242AFDED453F3D5B89C10F12F34@i2km99-ukbr.domain1.systemhost.net>
Message-ID: <456C8C79.3010404@kestral.com.au>
it got picked up by the webmaster as a suspicious post, and it waiting for
approval.
try
http://www.uploading.com/files/XUZIOCVC/xum.zip.html
Grahame
joseph.2.waller at bt.com wrote:
> Grahame,
>
> Should I have received a location for this?
>
> Thanks,
>
> Joe
>
>
> -----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, November 28, 2006 11:08 AM
> To: new-its at lists.hl7.org.uk
> Subject: [New-ITS] new XUM
>
> hi
>
> I am uploading a new XUM, it will be on uploading.com and a notification
> will arrive soon.
>
> this includes a new datatypes model, and XUMs for MIM 4, MIM 5, MIM 6,
> and all the September ballot. Since I am working through the HL7 Mifs,
> about 1/3 of them fail with some error or other. I am still whittling
> away on the error list.
>
> I have one change I'd like to make to the XUM, which is to make
> templateId an attribute. I will get to this soon.
>
> 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 postmaster at uploading.com Tue Nov 28 12:00:40 2006
From: postmaster at uploading.com (Uploading.com Informer)
Date: Tue, 28 Nov 2006 06:00:40 -0600
Subject: [New-ITS] Uploading File delivery
Message-ID:
Hello,
You've got a file called "xum.zip" (38.86 MB) from grahameg at gmail.com waiting for download.
You can click on the following link to download:
http://www.uploading.com/files/XUZIOCVC/xum.zip.html
The following message was included:
XUM for UML ITS
------------------------------------------------------------------------
Uploading.com - The best file hosting service!