[Nml-wg] XML syntax for NML relations

[Jason Zurawski]

All;

See inline a followup to an earlier promise I made:

On 8/26/11 9:46 AM, thus spake Jason Zurawski:
> Hi Jeroen/All;
>
> On 8/25/11 10:42 AM, thus spake Jeroen van der Ham:
>> Hi all,
>>
>> I've discussed with Freek yesterday, and I think the main issue here
>> is that there are different positions regarding validation and
>> parsing of XML files.
>>
>> Jason has the position of a programmer using some XML library to
>> parse XML files, create objects and general data out of it. The idea
>> is that you take an XML file handed to the program, process it and
>> make the best of it. There is no explicit validation. This seems
>> reasonably similar to how browsers process HTML files for example.
>>
>> Freek on the other hand was thinking of how XML is handled in the
>> SOAP/WSDL/Webservices world. There you have strict typing, explicit
>> validation, code generation, et cetera. Everything has to adhere to
>> reasonably strict schemas, otherwise most WS stacks refuse to work.
>>
>> While I understand that most of the NML files for monitoring will be
>> processed by PerfSONAR and similar tools, I would prefer that the
>> eventual schema would also be useful for WSDL style operations. I
>> know that the datatypes used there are reasonably strict, does anyone
>> know whether the current proposed XML schema is compatible with that
>> context as well?
>
> To some extent.  Certain fields can be typed, others it won't make sense
> to do.  The major objection (at least in prior mails) appears to be
> 'relation' being a generic chunk of XML that is hard to decode simply by
> syntactic validation.  The only way you can deference this is via a self
> enumerated list of possible 'types'.
>
> The type string would dictate what/how many of specific elements could
> be in there.  I can imagine a situation where you can get _limited_
> syntactic checking, but the tradeoff is that you would need to
> pre-define lots of these beforehand.  Let me self-assign an action to
> send a schema that describes this in some way.  I am not sure it walk
> calm the entire discussion, but it will be a good exercise.


See the following minor chunk of (unverified/unchecked) schema:

> namespace nml = "http://ogf.org/schema/nml/base/20110830/"
>
> NMLRelation = element nml:relation {
>     (
>         attribute type { "specifictype1" } &
>         NMLLink &
>         NMLLink
>     ) |
>     (
>         attribute type { "specifictype2" } &
>         NMLLink &
>         NMLPort
>     ) |
>     (
>         attribute type { xsd:string } &
>         # content
>     )
> }
>
> NMLLink = element nml:link {
>     # content
> }
>
> NMLPort = element nml:port {
>     # content
> }
>

The basic idea is that I have defined 2 'well known' relationships, but 
I have this 'anything else' sort of relationship to accept things I 
*don't* know about.  See the following minor chunk of XML:

> <!-- what the schema had in mind ... -->
> <nml:relation type="specifictype1" xmlns:nml="http://ogf.org/schema/nml/base/20110830/">
>   <nml:link />
>   <nml:link />
> </nml:relation>
>
> <!-- also what the schema had in mind ... -->
> <nml:relation type="specifictype2" xmlns:nml="http://ogf.org/schema/nml/base/20110830/">
>   <nml:link />
>   <nml:port />
> </nml:relation>
>
> <!-- not what the schema had in mind, but works ... -->
> <nml:relation type="specifictype1" xmlns:nml="http://ogf.org/schema/nml/base/20110830/">
>   <nml:link />
>   <nml:port />
> </nml:relation>
>
> <!-- something the schema shouldn't are about, works -->
> <nml:relation type="garbage" xmlns:nml="http://ogf.org/schema/nml/base/20110830/">
>   <nml:link />
>   <nml:link />
>   <nml:link />
>   <nml:link />
> </nml:relation>

#1 and #2 give the strict checking that appears to be desired.  But note 
that #3 is not what we want (still 'works' due to the backdoor of the 
'anything' check), and #4 is exercising our extension mechanism.  With 
one other change we can do this to the schema above:

>     (
>         attribute type { "unclassified" } &
>         # content
>     )

And force that anything we don't know about has to use a specific string 
in the type field.  Re-sending the XML through a verification field 
would mean that now #3 gets kicked out (as it should), and we would need 
to modify #4 to do the following:

> <!-- modified to pass the schema check ... we can do anything we want inside ... -->
> <nml:relation type="unclassified" xmlns:nml="http://ogf.org/schema/nml/base/20110830/">
>   <nml:link />
>   <nml:link />
>   <nml:link />
>   <nml:link />
> </nml:relation>

Personally I think this is a lot of work just to get semantic 
verification at the schema validation level, as a schema designer I 
would not want to do this.  Semantic validation is still better handled 
at the service level in my opinion, but I won't re-hash that argument 
now.

Thanks;

-jason

> Regarding WSDL, recall that there are different 'styles' of
> communication in web services world.  Here is a good intro:
>
> http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
>
> perfSONAR/NMC/NM are 'document literal', e.g. basically a complete XML
> document that contains meaning that we will decode on our own (in the
> processing code).  This makes it very hard to strongly type things to
> the same level that RPC varieties would.  Typically the RPC varieties
> lend themselves to automatic stub generation and the like.
>
> Thanks;
>
> -jason