glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Donal K. Fellows said: 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. :-)
The point is that changing the schema is hard (so far we've managed two updates in four years) so it's useful to have some generic way for people to add extra things we haven't thought of. However, it's rather limited (OtherInfo is just a string) so if someone wanted more structure they would have to impose it themselves and have some way of querying/parsing not supported in the basic schema. There is no particular reason for it to be csv, that's just an example - I'm still waiting for the first person to put XML in a GLUE string attribute! I think subclassing is a bit of a red herring, for ldap at least there is no way to change the schema at all without a large amount of effort - certainly an individual site can't do it.
You'd expose the strings to users? I wouldn't.
It depends what you call a user - at least people writing applications will need to know the identifiers, and I regularly query the current schema for particular service types just as an ad-hoc thing. We can have complex structured type names if necessary, but it isn't clear why it would be necessary. Stephen