Sergio Andreozzi wrote:
* Q. domain.otherinfo Looks like some random extensibility. It's not clear how much of that should be done by subclassing instead. And CSV? * A. for several entities, we envision the need of adding extra info; at the moment we offer two ways: - OtherInfo attribute, multi-value, single-dimension -- easy to use and query - Auxiliries Entity->Extension, support many instances, bi-dimensional (key,value) -- separate name from value, a bit more complex to query (CSV is just an example of possible synta)
In principle having a bunch of custom attributes is a reasonable thing to do (though it's an interop nightmare if you're not careful). But it is a proxy for subclassing, as that involves a statement that some set of attributes are meaningful together. I'm more concerned about CSV as a format as it requires a completely different querying approach to the sort of thing that I'd expect to use with the rest of Glue2 (i.e. a language like SQL or XQuery). Not that I have a good answer; it's more of a "watch out here!" sort of thing. :-)
* Q. Are all Endpoints web-services endpoints? * A. no
* Q. If not, consider defining a subclass WebServiceEndpoint and moving some of the current Endpoint attributes into it (e.g. WSDL URL, IssuerCA, TrustRootCA). * A. from the conceptual viewpoint this make sense; from GLUE viewpoint we want to avoid to create extra entities if not really needed since this will complicate the usability
When referring to WS endpoints, you really need WS-Addressing EPRs. Plain URLs aren't enough. (For why, talk to Dave Snelling as it's quite a long story and a bit outside my real expertise. But it has to do with the fact that EPRs can contain more than just an address.)
* Q. Categorizing by URI: Just define that a Compute Endpoint must have the Category URN set to, say, urn:OGF:Glue2:EndpointCategory:Compute (or you could substitute a URI or URL; it's an arbitrary string in the format of a URI, just like an XML namespace name is. I've not thought hard about the actual URN I gave as an example BTW, so I won't feel offended if you change it!) * A. they have to be defined yet (see tracker item artf6076); we agree that this is a meaningful approach, nevertheless this will reduce usability for users; when searching for a certain category of endpoing, they have to write a longer string, harder to remember;
You'd expose the strings to users? I wouldn't. Users are terrible at writing queries, and that's a fact that's been noticed over and over. They have whole books on how to write queries for Google for goodness sake, and that's virtually natural language! Instead, I'd expect users to pick a value (or maybe even a whole query template) from a suitable GUI element. Donal.