-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Currently the system does this for AttributeFilters:
XML: a <Filter> tag Perl API: addFilter webservice query API: described by type=attributes martview webpage: displayed in the attributes section What you are suggesting is for it to be treated solely EITHER as an Attribute OR as a Filter OR as a third, independent, AttributeFilter entity throughout all four sections mentioned above, rather than treated as different things in different parts of the system. I can see the logic in your argument, but ultimately it's up to Arek as to whether or not to change anything. Arek, what do you think? cheers, Richard. Bogdan wrote: > 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]>: > 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 iD8DBQFGgltO4C5LeMEKA/QRAkntAJ99GoT4bU094UtAijzNV4ISRq8eDgCgiNTM 6lG6lpWf9L45UPgVL6CfJb8= =cFmq -----END PGP SIGNATURE-----
