Members of the NML working group joined for two sessions at OGF 32. About 15 participants attended the sessions. Here are some notes; note that they are not complete (Jerry created some additional notes during the 1st session). However, I'll post them here now before I forget... :) At the first session, Jeroen van der Ham went through the RNC schema, explaining and correcting minor issues. The main topic on the table was the XML syntax for describing ordered lists. After some heated discussions, the participants agreed on the following syntax for an example of a link "link_A-to-C" is described as the concatenation of two smaller segments, "link_A-to-B", followed by "link_B-to-C". <nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.net:link_A-to-B"> <nml:relation type="next"> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C" /> </nml:relation> </nml:link> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C"> </nml:link> </nmlserialcompound:relation> </nml:link> A few notes are in place here: * As agreed earlier, the syntax does not rely on the order of the XML elements in the syntax (while most parser retain the order, this is not required by the XML specification.) Indead, the "next" relation is used to explicitly specify the order. * No explicit "first" or "last" element is specified. A "last" element in a list can be found by finding the item without a "next" relation. A "first" item in a list can be found by finding the only item in the list which has no pointer to it. * There can be only one "first" and "last" element in a list; this means that branching (e.g. an item with two "next" items) is not allowed; this should be described with another construct. * This means that * while it was argued that the "next" relation is a syntax construct, while the relations as defined in the NML UML schema are topology constructs, and thus different, the same syntax would be used to describe both relations. * The name of the topological relation in the above example is called "serialcompound" after Figure 10 of G.805 (of Figure 16 of G.800). The name was not great, but the participants were too tired to come up with something better :) * The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag. * At the end of the session, the participants had a discussion how to encode the relation type. In the above example, it is listed as '<nmlserialcompound:relation type="serialcompound">' and '<nml:relation type="next">'. While some arguments where laid forward, no definitive conclusion was reached. This topic remains open for discussion>. Finally, I like to thank all contributors to the discussion. It may have taken some time to talk some sense in me, that was due to my stubbornness, not due to the quality of the arguments. Those were in my opinion particularly good. A particular thanks to Jeff, Jason and Jeroen (the 3 J's) is certainly in place. Thanks, Freek
Hi Freek; A couple of comments and quibbles inline: On 7/16/11 4:13 PM, thus spake Freek Dijkstra:
Members of the NML working group joined for two sessions at OGF 32. About 15 participants attended the sessions.
Here are some notes; note that they are not complete (Jerry created some additional notes during the 1st session). However, I'll post them here now before I forget... :)
At the first session, Jeroen van der Ham went through the RNC schema, explaining and correcting minor issues.
The main topic on the table was the XML syntax for describing ordered lists. After some heated discussions, the participants agreed on the following syntax for an example of a link "link_A-to-C" is described as the concatenation of two smaller segments, "link_A-to-B", followed by "link_B-to-C".
<nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nmlserialcompound:relation type="serialcompound">
<nml:link idRef="urn:ogf:network:example.net:link_A-to-B"> <nml:relation type="next"> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C" /> </nml:relation> </nml:link>
<nml:link idRef="urn:ogf:network:example.net:link_B-to-C"> </nml:link>
</nmlserialcompound:relation> </nml:link>
A few notes are in place here: * As agreed earlier, the syntax does not rely on the order of the XML elements in the syntax (while most parser retain the order, this is not required by the XML specification.) Indead, the "next" relation is used to explicitly specify the order. * No explicit "first" or "last" element is specified. A "last" element in a list can be found by finding the item without a "next" relation. A "first" item in a list can be found by finding the only item in the list which has no pointer to it. * There can be only one "first" and "last" element in a list; this means that branching (e.g. an item with two "next" items) is not allowed; this should be described with another construct. * This means that * while it was argued that the "next" relation is a syntax construct, while the relations as defined in the NML UML schema are topology constructs, and thus different, the same syntax would be used to describe both relations. * The name of the topological relation in the above example is called "serialcompound" after Figure 10 of G.805 (of Figure 16 of G.800). The name was not great, but the participants were too tired to come up with something better :) * The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag.
It was discussed to modify the existing UML diagram to allow multiple entities in a relationship in accordance with this topic.
* At the end of the session, the participants had a discussion how to encode the relation type. In the above example, it is listed as '<nmlserialcompound:relation type="serialcompound">' and'<nml:relation type="next">'. While some arguments where laid forward, no definitive conclusion was reached. This topic remains open for discussion>.
My understanding of the last part of the meeting regarding this was that the NML group would move forward with the NMLBase namespace initially, and modifications to extension namespaces (e.g. 'nmlserialcompound' as you have in your above example) could be implemented to allow for more syntactic checks of a target XML snippet. As in perfSONAR, the concept of the 'base' needs to be much more forgiving than the more specific namespaces that other groups (or NML) would define if this level of syntactic checking is truly desired. All 'nml capable' services should at a minimum speak the base. For the sake of argument, this would be the 'base' way of specifying your example above: <nml:link id="urn:ogf:network:example.net:link_A-to-C"> <nml:relation type="serialcompound"> <nml:link idRef="urn:ogf:network:example.net:link_A-to-B"> <nml:relation type="next"> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C" /> </nml:relation> </nml:link> <nml:link idRef="urn:ogf:network:example.net:link_B-to-C" /> </nml:relation> </nml:link> Thanks; -jason
Finally, I like to thank all contributors to the discussion. It may have taken some time to talk some sense in me, that was due to my stubbornness, not due to the quality of the arguments. Those were in my opinion particularly good. A particular thanks to Jeff, Jason and Jeroen (the 3 J's) is certainly in place.
Thanks, Freek
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. Freek
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
Hi Jason, I was re-reading our mail, and I don't recall what you meant with the following comment:
On 7/16/11 4:13 PM, thus spake Freek Dijkstra: [...]
* The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag.
It was discussed to modify the existing UML diagram to allow multiple entities in a relationship in accordance with this topic.
Also thanks for your elaborate mail on extensibility. Freek
Hi Freek/All; On 8/16/11 6:09 AM, thus spake Freek Dijkstra:
Hi Jason,
I was re-reading our mail, and I don't recall what you meant with the following comment:
On 7/16/11 4:13 PM, thus spake Freek Dijkstra: [...]
* The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag.
It was discussed to modify the existing UML diagram to allow multiple entities in a relationship in accordance with this topic.
Someone, I believe it was Jeroen but I could be wrong, noted that the UML diagrams only allowed a single item in a relationship. Since many of our latest examples and thoughts revolved around being able to relate multiple items, I proposed that the UML diagram be altered to account for this. Thanks; -jason
Also thanks for your elaborate mail on extensibility.
Freek
Jason Zurawski wrote:
* The ordered list on itself is not enclosed in it's own XML tag (like <nml:list>), the elements are direct subelements of the parent <relation> tag. It was discussed to modify the existing UML diagram to allow multiple entities in a relationship in accordance with this topic.
Someone, I believe it was Jeroen but I could be wrong, noted that the UML diagrams only allowed a single item in a relationship. Since many of our latest examples and thoughts revolved around being able to relate multiple items, I proposed that the UML diagram be altered to account for this.
Ah, thanks! Indeed that is true and has to be changed. Thanks for the reminder. Freek
On 16 Aug 2011, at 15:58, Freek Dijkstra wrote:
Someone, I believe it was Jeroen but I could be wrong, noted that the UML diagrams only allowed a single item in a relationship. Since many of our latest examples and thoughts revolved around being able to relate multiple items, I proposed that the UML diagram be altered to account for this.
Ah, thanks! Indeed that is true and has to be changed. Thanks for the reminder.
I've updated the UML diagram to account for this: - added "next" relation from NO to NO (Network Object) - added 1 as value for "from" - added 1..* as value for "to" After some extensive searching today I also have to conclude that OWL2 does not have any support for lists in itself[1]. The only design pattern I could find[2] is basically the "next" relation that we've defined here. Jeroen. [1]: Yes, RDF supports Alt, Bag, Seq and List. OWL (1) then goes on to define them out of scope, unless you want to be in OWL Full. OWL2 does not define anything regarding lists or sequences, I guess they still follow the idea from OWL 1 and disallow them unless you want to use OWL Full. Since that would basically preclude NML from being used in OWL-reasoners, I'd rather not go for that unless absolutely necessary. [2]: http://www.w3.org/TR/2006/NOTE-swbp-n-aryRelations-20060412/#pattern2
participants (3)
-
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham