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. > > 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. - thomas
