Hi Freek; On 7/16/11 4:43 PM, thus spake Freek Dijkstra:
Thanks for the quick feedback, I download it now and read later.
I remember you and Jeff made a distinction between unknown element and unknown namespace. Could you elaborate sometime coming week? I notice I didn't write that down.
Ok, I will try to explain the background, but it may be very long :) In a nutshell, perfSONAR web services all speak a common dialect of request/response message - the 'nmbase' (http://anonsvn.internet2.edu/svn/nmwg/trunk/nmwg/schema/rnc/nmbase.rnc) schema as well as a specific language that relates to their functionality (e.g. MP Protocol) and data type (e.g. BWCTL). These are are hierarchical. Any and all messages, no matter which service is using them, should conform to this basic schema. It is not very strict, basically describes the message, some of the required elements (ids, metadata and data, etc.), and the world famous (infamous?) 'anyElement'. This last portion allows us to allow in any element (in any namespace) that we have never heard of. A blank check for submitting any XML - as long as its syntactically correct. This may seem like a *horrible* idea, but the *only* reason the base schema exists at all is to serve as a model for all other schemata that follow. It has to be permissive, because it is assumed that future schemata would be more strict about what they accept/deny. Lets look at one, the EchoRequest (http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-SNMPMA/etc/...), which is a specialized version of the nmbase. You don't need to know much about RNC, but there is a line that starts with 'include "support/nmbase.rnc" {' wherein we are re-defining the concepts in the nmbase. Instead of using the all inclusive metadata, we are making a more specific structure (metadata/data) that makes sense for Echo Messages. Back to our service example - If a service is only validating messages against nmbase, and the EchoRequest instance (http://anonsvn.internet2.edu/svn/perfSONAR-PS/trunk/perfSONAR_PS-SNMPMA/etc/...) comes in, it will instantly validate against the nmbase. If the service is capable of speaking the EchoRequest dialect, there is a chance the service may try to validate against this schema as well and it should succeed. An example that treats things the 'opposite' way would be if some perfSONAR service wasn't validating against NMBase, but choosing to use only some more specific schema. If you sent a message that was not constructed using this very specific type, odds are it would fail. This is where a priori knowledge of special schemata would be needed. These special namespaces are perfectly capable of adding in new elements (e.g. I could for instance make a 'http://ogf.org/ns/nml/freek/' namespace and insert the 'is_awesome' element), but 'new' elements don't transfer back up the chain to the 'head' so to speak. The would work if someone accepted 'anyElement', but may be rejected for lack of knowledge of the namespace in other cases. The 'chameleon namespace' design (http://books.xmlschemata.org/relaxng/relax-CHP-11-SECT-5.html) describes this - allowing the re-use of elements in child namespaces. Often the syntactic validation is skipped (its expensive, and not very useful), and semantic rules in the code act on messages instead. E.g. in perfSONAR we take clues from the message type, and the eventType to process the structure of the message. This is how we kick out messages for the most part, instead of needing to exchange schemata dialects in an out of band process. I hope this helps; -jason