2006/5/16, Thomas Beale <Thomas.Beale at oceaninformatics.biz>: > > Mattias Forss wrote: > > > > > > 2006/5/16, Sam Heard <sam.heard at oceaninformatics.biz > > <mailto:sam.heard at oceaninformatics.biz>>: > > > >> > > Well, we do not think it is only a matter of display - although it > > could be seen as such. If the attribute is not present then it is > > not possible to determine whether to display it as a pivot or not. > > The property of DV_QUANTITY is only in the archetype as well and > > determines valid units - it is a similar sort of issue. > > > yes, but that's only because we have an explicit custom type called > C_QUANTITY that supplies the "property" attribute in the archetype. > Otherwise this would not be possible > > > > Hi again Sam, > > > > > > I wouldn't mind to ignore and not save this attribute until the > > different display modes are supported in the Java archetype editor. A > > missing rotated attribute should probably not cause errors for the > > Ocean archetype editor? > This cannot work as explained above - either the attribute has to exist > in the RM class or else we have to create a custom type like > C_ITEM_TABLE for it. That's the general rule.
Hi Tom, I agree with you. Either the rotated attribute is removed from the archetypes or added in the ITEM_TABLE or a custom type C_ITEM_TABLE. > > >> Now to the important question that I'd been thinking about. The > >> specifications of ITEM_TABLE say that the rows attribute should > >> have a List<CLUSTER> as children but I don't see the point with > >> this. Why do we need several clusters as rows since a table with > >> rows that each have different column headings is impossible to > >> create? If the rows attribute had List<ITEM> as children it would > >> make much more sense. > > > I don't understand that....the current specification says that each row > is logically a CLUSTER (of ELEMENTs). Of course there are more efficient > ways to represent tables, but we have stuck to the tree structure used > in CEN EN13606 - it is interoperable and simple to understand. Yes, I guess we're stuck for a while then... So you shouldn't worry that this structure could technically allow different > column names on different rows, the software will not allow that. You > get a bit of redundancy in using sub-optimal structures for > interoperability purposes. I think we keep flipping around things here. I take it from the point of creating the actual RM data. What I think you mean is that if someone is clumsy it would be quite easy to create two rows with the same column name (not heading), e.g. "Left"? This is quite a flaw but as long as the software (kernel) won't allow this creation it's acceptable. > > > So then I guess the ADL is constructed according to how the first > > table looks like in your example above (since pivot should not affect > > the structure)? In that case I believe that the ITEM_TABLEs that are > > created by the Ocean editor aren't following the specifications, since > > no matter how many rows ( e.g. left, right) you add, they will only be > > contained within one cluster only. There is accordingly no way to > > create an ITEM_TABLE that has more than one cluster under the rows > > attribute. > In the archetype you would only have one row, since it is a model for > numerous rows in the data...does that answer the question? Yes it does, but not how the column names/headings (depends what you mean if it's displayed as a pivot table or not) are modelled in archetypes, e.g. "left", "right" for a reflexes archetype. They are modelled as the first ELEMENT in Ocean's archetypes and it contains a CODED_TEXT that constrain the headings. Is this the best way to represent headings? I don't understand the logic behind it since they can be mistaken for actual table data which comes after the first element. However, column names/headings are table data too but it's bad design to assume this comes first in order to show the table in an archetype editor. Maybe I could take a different approach than actually showing a real table in the GUI... > Furthermore, each row that is added should create a cluster that has > > an at-code with its name and in the pivot display mode the clusters > > names will be the column headings. Right? > this is getting mixed up between rows in an archetype (don't forget an > archetype is not data, it is a model of data) and the actual data that > conform to the archetype - which will of course have >1 rows in general. No I haven't forgotten about that but sometimes it's easy to think a step ahead. :-) Regards, Mattias - thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060516/e546a52f/attachment.html>
