Dear Richard, thank you for explanation.
However, as far as I understand both the response to '?type=filters&dataset=' and the 'XML' page in martview are generated by the same web-services API; if this is the case, then why do we find 'upstream_flank' in 'attributes' in one case, and 'filters' in another? wouldn't it be logical to standardize the web-services API response for AttributeFilter(s)? So that 'upstream_flank' falls only in one group - either attributes or filters - across all the API, irrespective of the web-service querying method. 2007/6/27, Richard Holland <[EMAIL PROTECTED]>:
-----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-----
-- Sincerely yours, Bogdan Tokovenko, PhD student at the Laboratory of Protein Biosynthesis, Department of Genetic Information Translation Mechanisms, Institute of Molecular Biology and Genetics, Kyiv, Ukraine http://bogdan.org.ua/
