[Nml-wg] Session notes for NML

[Jason Zurawski]

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/schema/EchoRequest.rnc), 
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/requests/EchoRequest.xml) 
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