-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is deliberate.
'upstream_flank' is something called an AttributeFilter - it is an attribute because it appears in the attribute pages, but it is also a filter because it has a user-specified value. The web services API has to choose between treating it as one or the other (there is no query for type=attributeFilters), and so it chooses Attribute. The choice is arbitrary - one could make a logical argument for it to live in either section, but it can only live in one and so Attribute was chosen. cheers, Richard Bogdan wrote: > Dear all, > > when using the 'XML' button in martview, and asking for > upstream_flank, we may get something similar to this: > > <Filter name = "upstream_flank" value = "800"/> > <Attribute name = "gene_stable_id" /> > <Attribute name = "5utr" /> > > In the system I'm building, there's an automatic check for the > correctness of attributes and filters in generated queries. Attributes > and filters are checked against the lists, returned by > ?type=attributes&dataset= > and > ?type=filters&dataset= > requests, respectively. > > However, 'upstream_flank' is not present in the list of filters; it is > present in the list of attributes, though. > > This looks somewhat inconsistent to me. For now, I introduced a small > hack to my code to bypass 'upstream_flank' when checking. > > Is there any explanation/grounds for this design of the system? > > Thanks beforehand, > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGglGQ4C5LeMEKA/QRAqMTAJ9VAPyCSfqekzEjjXe/0xVSAhivPgCfUukY LyL4C8IlUfjA62Y5zliUXqY= =mxcY -----END PGP SIGNATURE-----
