> Regarding vector vs. map, after thinking about it a bit, I agree with you that
> map<> would be at least a bit better user experience. However,
> ItemFactory::createElementNode() takes a vector<pair<>> already, and that
> can't be changed. I think probably it's best that getNamespaceBindings() be
> consistent with that API.
Fair enough.
>
> In fact, probably createElementNode() should be changed to use the same
> typedef as getNamespaceBindings(). Should I move the typedef for NsBindings
> into store_consts.h?
No, I don't think so. Because the internal NsBindings uses zstring (not zorba::String)
> Regarding vector vs. map, after thinking about it a bit, I agree with you that :createElementN ode() takes a vector<pair<>> already, and that dings() be
> map<> would be at least a bit better user experience. However,
> ItemFactory:
> can't be changed. I think probably it's best that getNamespaceBin
> consistent with that API.
Fair enough.
> dings() . Should I move the typedef for NsBindings
> In fact, probably createElementNode() should be changed to use the same
> typedef as getNamespaceBin
> into store_consts.h?
No, I don't think so. Because the internal NsBindings uses zstring (not zorba::String)