I hesitate to bring this forward, what with some folks' (very reasonable) pleas to keep things simple, but the idea of namespaces arose during offline discussion. The thinking is that, as the number of tags increases, the potential for tag name collisions also increases (in particular with custom tags). The well known way to avoid this is by partitioning tag names into namespaces. A simple way to do this would be to prefix a tag name with a grouping name, separating them with a :, such as is done in XML.
To avoid instant complication of all existing systems, we could say that a tag without a : is a standard Haystack tag. But a prefix of, say, "h:" also means the same thing. Queries would have a default namespace of "h", but could possibly declare an alternate so that the tags need not be explicit namespaced. Integrators could safely create custom tags using their own prefix, e.g. "myco:point". (There is the possibility of grouping name collision, but much less probability, and they would also be easier to fix.)
The real value would be in the ability to create whole new tag libraries for different domains, such as user management.
Regarding declaration (and with respect to my previous i18n post), declarations could be provided at the beginning of a query, a la:
[ns:users, lang:fr] (followed by a french language user-domain query)
I haven't checked whether this syntax conflicts with any existing query constructs... just throwing it out there. Actually, i suppose declarations could be in a separate post.
Brian FrankFri 28 Jun 2013
We started the project off that way and it quickly become a quagmire because many terms cross the logical domains you would use for namespaces. Plus we felt that it would be bad to reuse the same term in different domains/namespaces - you can always pick a good unique name. So it was a massive simplification to collapse into a single global namespace. Although we still will use prefixes to ensure uniqueness in some cases (which is really all a namespace does in a more complicated way). I've also found a lot of inspiration from Wikipedia which describes the entire world with a single global namespace.
Matthew LohbihlerMon 8 Jul 2013
We started the project off that way and it quickly become a quagmire because many terms cross the logical domains you would use for namespaces.
I would submit that this occurred because you are not actually dealing (yet) with different logical domains. Building control is a single, albeit large, domain. Others that might be different could include data center management (many similarities but many differences, but with an overall narrower scope), or home automation. Very different domains would likely include user management, retain inventory, software libraries, ...
I would go as far as to suggest that the Haystack tag library and the query language (and REST impl) should in fact be separate projects.
Christopher PiggottMon 8 Jul 2013
I would go as far as to suggest that the Haystack tag library and the query language (and REST impl) should in fact be separate projects.
I don't want to pollute this discussion but in my fork I'm on the path of doing exactly that - separating out the core object model from the server, client, and other stuff. I really want to use JAX RS for the REST server and jackson for json serialization.
Matthew Lohbihler Fri 28 Jun 2013
I hesitate to bring this forward, what with some folks' (very reasonable) pleas to keep things simple, but the idea of namespaces arose during offline discussion. The thinking is that, as the number of tags increases, the potential for tag name collisions also increases (in particular with custom tags). The well known way to avoid this is by partitioning tag names into namespaces. A simple way to do this would be to prefix a tag name with a grouping name, separating them with a
:
, such as is done in XML.To avoid instant complication of all existing systems, we could say that a tag without a
:
is a standard Haystack tag. But a prefix of, say, "h:" also means the same thing. Queries would have a default namespace of "h", but could possibly declare an alternate so that the tags need not be explicit namespaced. Integrators could safely create custom tags using their own prefix, e.g. "myco:point". (There is the possibility of grouping name collision, but much less probability, and they would also be easier to fix.)The real value would be in the ability to create whole new tag libraries for different domains, such as user management.
Regarding declaration (and with respect to my previous i18n post), declarations could be provided at the beginning of a query, a la:
I haven't checked whether this syntax conflicts with any existing query constructs... just throwing it out there. Actually, i suppose declarations could be in a separate post.
Brian Frank Fri 28 Jun 2013
We started the project off that way and it quickly become a quagmire because many terms cross the logical domains you would use for namespaces. Plus we felt that it would be bad to reuse the same term in different domains/namespaces - you can always pick a good unique name. So it was a massive simplification to collapse into a single global namespace. Although we still will use prefixes to ensure uniqueness in some cases (which is really all a namespace does in a more complicated way). I've also found a lot of inspiration from Wikipedia which describes the entire world with a single global namespace.
Matthew Lohbihler Mon 8 Jul 2013
I would submit that this occurred because you are not actually dealing (yet) with different logical domains. Building control is a single, albeit large, domain. Others that might be different could include data center management (many similarities but many differences, but with an overall narrower scope), or home automation. Very different domains would likely include user management, retain inventory, software libraries, ...
I would go as far as to suggest that the Haystack tag library and the query language (and REST impl) should in fact be separate projects.
Christopher Piggott Mon 8 Jul 2013
I don't want to pollute this discussion but in my fork I'm on the path of doing exactly that - separating out the core object model from the server, client, and other stuff. I really want to use JAX RS for the REST server and jackson for json serialization.