As a map-like (string->string) structure I use properties like @map1-key=value and @map2-key=value. Now I need to define different definitions for map1 & map2 properties (say not have map2 ones in index).
Sure it's not something that must be this way. I solved this by moving map2 ones into a new child node so they became like map2/@key=value. But why forcing the structure if there's nothing against enabling patterns? I guess this pattern of naming nodes & properties is used a lot (for map-like access in browsing), and now if we want different types for two maps they should be separated into two nodes. On Fri, Apr 8, 2011 at 6:02 PM, Jukka Zitting <[email protected]> wrote: > Hi, > > On 04/08/2011 03:25 PM, Omid wrote: >> >> I expected to be able to use patterns for name of node& property >> definition in node types. But it doesn't work, and it's mentioned in >> specification that other than simple name, only * pattern can be used >> that matches all unmatched items with property type. Is there a reason >> for not allowing more flexible patterns? >> >> I had a look into source and it seems fairly easy to implement this, >> should I go on and do so? > > Do you have a good use case where you'd need such a feature? Why can't that > use case be covered with the existing * pattern? > > -- > Jukka Zitting >
