Hi Freek; On 7/16/11 4:39 PM, thus spake Freek Dijkstra:
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).
Just to confirm ... do you mean to say '<serialcompound:relation>' where the 'serialcompound' namespace is something defined in addition to the nml base namespace? This would foster use of the same element 'relation' in both the base and subsequent namespaces (for reference the concept is described here: http://books.xmlschemata.org/relaxng/relax-CHP-11-SECT-5.html). In your example above you have created a new element, which would imply a special case instead of using the relation element at all. Since this is a complicated construct I do want to be sure we are all on the same page. Thanks; -jason
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