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. > >> 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. 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. > >> Also, It wouldn't be a bad idea to have rows and column headings >> as separate attributes instead of having the column headings of >> the table in the first element under the rows attribute. > Well, each row is a set of elements (as a cluster) - the table is > a special case in that each cluster can only have elements > (invariant). Each row is a cluster - which is in effect the > definition of each column. So you need a list of clusters to get rows. > > > 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? > 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.
- thomas
