Now the same message but the last sentence in better English :) (sorry for that)
On 09/23/2013 10:38 AM, Thomas Beale wrote: > On 20/09/2013 20:40, Bert Verhees wrote: >> Op 20-9-2013 17:01, Thomas Beale schreef: >>> it's simpler than you think - we made that property mandatory so >>> that programmers would never get a null exception. >> Must have been along time ago, nowerdays, programmers have no problem >> handling a null property. > > actually, that's not quite true. It's probably the primary reason for > exceptions in object-oriented software - method call on a void object. > But I get what you are saying, and for this String field, being null > would not pose a great problem. So we could change the spec to do that. Yes, it is very easy to catch a null-exception and then do something with that information. Anyway, IMHO, specs should not solve technical problems, and they mostly don't do that. I believe this is also defined in UML. Technical problems are for implementers to solve. That is why this is a strange decision. > >> >> I wonder what the idea behind stuffing the archetype_id in the >> archetype_node_id property is? >> Here you make it harder for programmers because the archetype_id has >> another syntax in archetype-paths then the archetype_node_id has, and >> anyway, lots of other functions, and a programmer has to check the >> string-layout to find out if it is an archetype_id or an >> archetype_node_id. It also blocks the possibility to store the >> "at"-code for the root, and check the ontology for its contents. > > the idea is that there is only one field to look at to find archetype > identifying information in data. It is either an archetype_id (string > form) or an at-code, or (for systems that support it) it's empty / > 'unknown' (which could be replaced by null/void). With the archetype > id, you can always look up the archetype and find out the root code > (at0000, or a matching pattern like at0000.1 or at0000.1.1). But if > you can't look up the archetype, you are lost, and that's what the > archetype_id is for. The point is, the archetype_id is stored in the property archetype_node_id, Pablo implemented it like that in XML, and he found in the specs it should be that way. I think this is an unneeded complication of the specs. Better was to assign a special property for the archetype_id, besides the archetype_node_id. He found this spec in common.pdf, section 3.1.2 where is stated: "The archetype_node_id is the standardised semantic code for a node and comes from the corresponding node in the archetype used to create the data. The only exception is at archetype root points in data, where archetype_node_id carries the archetype identifier in string form rather than an interior node id from an archetype." This makes it difficult to implement, because, an implementer has to test if the archetype_node_id contains an at-code or an archetype_id. This can lead to ambiguities, for example if XML contains the archetype-slots and the connected instances are embedded, which is legal and can really speed up XPath-queries. These possible ambiguities can occur because it is not really hard defined what an at-code looks at. Bert > > - thomas > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130923/191eec15/attachment-0001.html>
