Since we are using a relational diagram which does not fit in a tree (that is the reason why we need foreign keys), I would also recommend not to force the DIT, but rather make recommendations on how to implement it. Right now Laurence is working on it. Regards, David On Thu, Apr 16, 2009 at 5:40 PM, Burke, S (Stephen) <stephen.burke@stfc.ac.uk> wrote:
Paul Millar [mailto:paul.millar@desy.de] said:
Having read (only the relevant bits of ;-) RFC-4511 I couldn't find anything to suggests that one cannot use substring match rules in an extensible filter.
My experience was more practical, I tried it and observed that it didn't work! However, with more time to think about this I'm not sure it's directly relevant anyway. The current use for the chunkkey is to relate objects with only a LocalID to their parents, but we now have global IDs for everything so I think we can just use the same kind of key for all relations. At a quick look I don't see any case where we have both parent and non-parent type relations between the same object classes, but if we do we should probably treat them as independent relations. (Hmm ... AdminDomains? Sites belong to both EGEE and LCG, but neither of those is a parent of the other, so EGEE -> LCG has a different status to EGEE -> DESY. But looking at the diagram we don't seem to allow for peer relations at all, so EGEE can't relate to LCG :)
Anyway as I said earlier this is closely coupled with the question of how we structure the DIT - my personal preference is that we should try to avoid prescribing a particular tree, which would imply that you shouldn't need to do extensible queries. Also the schema is rather more complex than a tree can capture so I think we're bound to end up with relations that go outside it - e.g. Benchmark seems to be a "child" of both ExecutionEnvironment and ComputingManager.
What we may perhaps want to think about is whether we might want any "double hop" references. For example, ExecutionEnvironment is not directly related to ComputingService (or DataStore to StorageService). Obviously you can get the link by doing two queries, but if it's likely to be a common thing it could be useful to have it explicitly?
However, even this is immaterial since clients MUST NOT (as in RFC 2119) conduct wildcard searches against the DN.
I take your point, but there are different grades of clients - I often construct ad-hoc queries which use properties I happen to know are true (or maybe just "mostly true") even though they aren't mandated by the schema. That would be naughty in real production code, but can be useful on the fly. And conversely I don't think I've ever used an extensible query in a real-world case, only to test it.
Stephen
-- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Professional Web: http://cern.ch/horat Personal Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat