On 25/04/2013 18:52, Diego Bosc? wrote: > You can generate operations to deal with domain types, but then AQL > would be openEHR specific (you can call it OQL then). What I say is
Diego, there is nothing openEHR-specific today in AQL, and allowing more complex primitive types like dates or codes or URIs doesn't change that. It will work just as well with any reference model from any industry. So I don't get your point here. > that generating a path to specify a filter (and accessing it) is > direct when the domain type has been expanded, and not so easy if you > take it as it is. If you get the expanded path each time then the user > won't be able to tell where the AQL path comes from (it'll have > attributes he doesn't know about). I only see disadvantages working > with domain types in AQL. > but in that case you should be arguing that we should remove the Date/Time types and URIs etc. It's true, we can just limit ourselves to Integer / Real / String / Character / Boolean / Binary, but... why? It's just making life needlessly difficult as far as I can see. - thomas
