Hi all, Let me follow up on a technical part of yesterday's discussion.
At the end of the session, we had a discussion on how to encode the relation name (here: "serialcompound") in XML. E.g. each relation as a different element, a different attribute, or a different value of a fixed attribute.
So far, the relation type is encoded in the value of a type attribute (e.g. <nml:relation type="serialcompound">). Freek pointed out that this makes it harder to create a meaningfull schema for validation. For example, there is a difference syntax associated with next relations and serialcompound relations. <nml:relation type="serialcompound"> may contain 0 or more children, while <nml:relation type="next"> must contain exactly one child. The RNC schema does provide a means to specify this difference. Jeff confirmed this and pointed out that it is of course still possible to check the syntax using other logic, it is just not possible to create a detailed schema. (Freek pointed out that NMC has the same problem, which is the reason that no non-trivial WSDL was created for perfsonar, and no software used a SOAP library, despite that most NMC messages are embedded in a SOAP envelope). The encoding of the type of relation in a element (e.g. <nml:serialcompound>) allows more meaningful validation. However, this has another drawback: if a client does not know about a particular relation, it does not know if the unknown element is subclass of a relation and can or can not be ignored. In fact, it can not even do basic syntax checking (as if it was just a unknown NML relation), since it does not know it is a NML relation without parsing the schema definition (which will list the new element as a subclass of the base element). So there seem to conflicting requirements: * ability to do extended validation * know from just looking at XML (but not the schema) that something is a NML relation It may be possible to find a solution that caters to both requirements. For example, in NM, subclasses use the same name (a trick known as chameleon namespace in RNC). E.g. A subclass of e.g. http://schema.ogf.org/nm/base/port is also called "port", e.g. http://schema.ogf.org/nm/layer2/port. A similar trick is enforce that all relations must always be defined in the same namespace (which may only contain relations). E.g. everything that starts with http://schema.ogf.org/nml/relation/ is a relation. I think we should discuss this further. I know the above is a difficult technical discussion, so I appreciate that you read so far. Please provide feedback if this was clear, and if you have any opinion or thoughts on this topic. Regards, Freek