The problem with an information model is that we can end up describing everything. The aim of Glue within OGF is to try and bring some of the other specifications together and not define so much by ourselves. For example, JSDL should describe the job and Glue should reflect this so that the job can be matched. The group defining JSDL should worry about the matchmaking should be worked out jointly between the JSDL group and Glue, but JSDL should be the definition which Glue reflects and likewise for the Authorization. We need to narrow our focus or we will end up "boiling the ocean" which has happened to many other Groups and the definition will take forever. From what I can see on the use of DENY tags within EGEE, this is a big hack to work around a implementation problem in the glite middleware and as such should not dictate what is done in Glue. We should just be able to published the ACLs in the FQAN format and that is it. The reason for the DENY tags is the inconsistency with the simple matchmaking done by the WMS and the mapping of VOMS FQANs in a CE. If publishing only the FQANs does not work, it is not necessarily an information model problem but architectural issue that needs to be fixed and should be pushed back to those dealing the Authentication and Authorization. We need to take a more minimalistic approach do the schema definition and not try to fix other peoples problems. I completely realize that we need to be pragmatic but just like over design we can also be too pragmatic.
The syntax of the FQAN itself is defined by the VOMS developers, but they don't consider how it should be published in GLUE, or in general how it should be used for matching. This is similar to the situation with access protocol names - in principle they should be defined by SRM, but in practice they aren't so we have to do it. Indeed the recent review of authorsiation in EGEE basically endorsed the GLUE model and will change both the WMS and LCMAPS to follow it!
Stephen