January 2013 - nml-wg - lists.ogf.org

Fwd: tnc2013:The Network Markup Language (NML) - A Standardized Network Topology Abstraction for Inter-domain and Cross-layer Network Applications
by Jeroen van der Ham 28 Jan '13

28 Jan '13

Begin forwarded message: > From: CORE <webmaster(a)terena.org> > Subject: tnc2013:The Network Markup Language (NML) - A Standardized Network Topology Abstraction for Inter-domain and Cross-layer Network Applications > Date: 28 January 2013 14:57:33 CET > To: Jeroen van der Ham <vdham(a)uva.nl> > Reply-To: CORE admins <webmaster+core(a)terena.org> > > TNC2013 Conference. > > Dear Jeroen van der Ham, > > On behalf of the Programme Committee, it is my pleasure to inform you that your submitted paper entitled "The Network Markup Language (NML) - A Standardized Network Topology Abstraction for Inter-domain and Cross-layer Network Applications" has been accepted for presentation at the TNC2013 Conference. > > At present, you are scheduled to speak in a session on Wednesday 05 June, from 14:00-15:30. Your session chair will be Zenon Mousmoulas (zmousm(a)admin.grnet.gr) Please note that these details are subject to change.Comments from the programme committee: > > * Interesting abstract. > * Spend a good time in your presentation on the 'A use case for NLM'. Thus making it concrete (as a language can be experienced as very abstract/boring). > > > > You will be hearing from us again very shortly, but in the meantime you should take the following steps to complete your involvement in tnc2013: > > 1) Sign in to CORE: https://tnc2013.terena.org/core/user/login. > > 2) Update your personal information by clicking "Edit account" in the top right corner. The information you enter will be shown on your 'Speaker Details' webpage. This includes a landscape profile picture (minimum 300 x 200 pixels), a short biography (max 100 words). You should also make sure your name is spelled correctly and that the organisation which you will be representing is correct. Also check that the details of the presentation assigned to you are correct. > > Sincerely, > > >

1 0

XML Topology document
by Jeroen van der Ham 28 Jan '13

28 Jan '13

Hi, At the moment there is a discussion on the NSI mailinglist about the preferred syntax for NSI topology descriptions. There is now an example document at https://github.com/jeroenh/AutoGOLE-Topologies/blob/nsiv2/goles/nordu.net.x… I've tried to do some XML schema verification on that file, and I've got it down to two errors: goles/nordu.net.xml:2: element Topology: Schemas validity error : Element '{http://schemas.ogf.org/nml/2012/10/base#}Topology', attribute 'version': '20120814' is not a valid value of the atomic type 'xs:dateTime'. goles/nordu.net.xml:64: element Node: Schemas validity error : Element '{http://schemas.ogf.org/nml/2012/10/base#}Node': This element is not expected. Expected is ( {http://schemas.ogf.org/nml/2012/10/base#}Relation ). goles/nordu.net.xml fails to validate The first I understand sort of, some kind of strict typing must occur. The second problem I'm not sure, I thought we had defined the hasPort relation to be defined as an implicit relation, so it should be necessary to define it? Jeroen.

2 3

Topology Syntax document
by Jeroen van der Ham 25 Jan '13

25 Jan '13

Hi all, I've prepared a document defining the NSI topology syntax extensions on NML. This basically codifies the syntax that we have been using in the Automated GOLE demo since SC. Feedback (and approval) is more than welcome! Jeroen.

1 0

NML at OGF 37
by Freek Dijkstra 23 Jan '13

23 Jan '13

Hi, Who is planning on going to OGF 37 in Charlottesville? I'm planning to go there. Regards, Freek

4 4

NML Schema document submitted
by Jeroen van der Ham 22 Jan '13

22 Jan '13

Hello all, I have just submitted the NML Schema document to the OGF editor: http://redmine.ogf.org/issues/56 Thank you all very much for your input and help with this document. Let's hope the review process will be a swift and painless one :) Regards, Jeroen.

1 0

Commits
by Freek Dijkstra 21 Jan '13

21 Jan '13

FYI, I just pushed a few commits. The most important changes are: • Section describing how to combine multiple descriptions of the same object. • Text about unnamed objects (without id) (see issue #45) • Allow encoding attribute for Bidirectional Port and Bidirectional Link • Add list of all attributes with pointer to where they are defined. • Add list of all parameters with pointer to where they are defined. • Explain how objects, attributes, parameters and relations are represented in XML • Explain how objects, attributes, parameters and relations are represented in OWL Roman -- could you take a look at the "labeltype" attribute? I think it is still "type" in XSD and XML examples. See also https://forge.ogf.org/sf/go/artf6577 Regards, Freek

2 1

Review of the XSD schema
by Freek Dijkstra 18 Jan '13

18 Jan '13

Here is my review of the XSD schema. Since I'm less verbose in XSD, it's mostly a series of questions. First of all I really like to compliment Roman -- you have been able to even add rather complex constructs like implicit and explicit relations. I also now understand the pros and cons of XSD much better (after having read parts of the primer http://www.w3.org/TR/xmlschema-0/, as well as the discussion http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html and rebuttal http://www.imc.org/ietf-xml-use/mail-archive/msg00261.html -- see further follow-ups for a nice cozy flamewar which may keep you warm during the long cold nights during this winter season.) General questions and remarks: ------------------------------ * Where does it specify that all NML descriptions should start with nml:Topology as the root element? * In the current schema, the order of child elements is very strict -- it is a sequence of elements in particular order. For example, a relation element MUST occur before a Location element. If relation occurs after a Location, the document is invalid. Here is an excerpt for the schema: > <xs:complexType name="NetworkObject"> > <xs:sequence> > <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/> > <xs:element name="relation" type="nml:RelationType" minOccurs="0" /> > <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1"/> > <xs:element name="parameter" type="nml:ParameterType" minOccurs="0"/> >  > </xs:sequence> >  > </xs:complexType> Instead, I would suggest to use xs:all: > <xs:complexType name="NetworkObject"> > <xs:all> > <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/> > <xs:element name="relation" type="nml:RelationType" minOccurs="0" /> > <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1"/> > <xs:element name="parameter" type="nml:ParameterType" minOccurs="0"/> >  > </xs:all> >  > </xs:complexType> In XSD 1.0, this would limit the maxOccurs to 1, but XSD 1.1 no longer has that restriction. Given that XSD 1.0 and XSD 1.1 use the same namespace, perhaps it is good to make this explicit: > <xs:complexType name="NetworkObject"> > <xs:all> > <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1" /> > <xs:element name="relation" type="nml:RelationType" minOccurs="0" maxOccurs="unbounded" /> > <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1" /> > <xs:element name="parameter" type="nml:ParameterType" minOccurs="0" maxOccurs="unbounded" /> >  > </xs:all> >  > </xs:complexType> * I don't really understand how you are trying to deal with implicit and explicit relations. This seems at first very powerful (meaning: either use implicit or explicit): > <xs:choice> > <xs:element name="lifetime" type="nml:LifeTimeType" minOccurs="0" maxOccurs="1"/> > <xs:element name="existDuring" type="nml:ExistDuringType" minOccurs="0" maxOccurs="1"/> > </xs:choice> In fact there are four ways to represent implicit relations: 1. <nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Location> <nml:name>Somewhere</nml:name> </nml:Location> </nml:Node> 2. <nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Relation type="http:....nml/base#locatedAt"> <nml:Location> <nml:name>Somewhere</nml:name> </nml:Location> </nml:Relation> </nml:Node> 3. <nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Location id="..." /> </nml:Node> <nml:Location id="..."> <nml:name>Somewhere</nml:name> </nml:Location> 4. <nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Relation type="http:....nml/base#locatedAt"> <nml:Location id="..." /> </nml:Relation> </nml:Node> <nml:Location id="..."> <nml:name>Somewhere</nml:name> </nml:Location> Currently, for Location/locatedAt only the form 1 seems allowed. For LifeTime/existDuring only forms 1 and 3 seem allowed. Is this on purpose? (I presume it is on purpose that the explicit variants are not listed, but that the missing form #3 for Location is a omission.) * To iterate on existsDuring: It seems that the described form it even slightly different: <nml:Node id="..."> <nml:name>My Device</nml:name> <nml:existDuring idRef="..." /> </nml:Node> (thus without the <nml:LifeTime> wrapper) Is that interpretation correct? * The RelationType lists all possible relation URIs as values for the type attribute. Is it permitted to use a URI not listed here? Thus, is is possible to define a new relation in nml-experimental, without changing nml-base? Specific remarks: ----------------- > <xs:attribute name="idRef" type="xs:anyURI" use="optional"/> Remove line 32, as idRef is no longer used: > <xs:element ref="nml:Port" minOccurs="1"/> Remove minOccurs on line 40: (perhaps the minOccurs should be listed elsewhere?) > <xs:attribute name="version" type="xs:unsignedInt" use="optional"/> version type should be a dateTime on line 33: For readability, I suggest to put xsd:attribute before xsd:elements, in particular for NetworkObject and RelationType. (Simply because attributes also come earlier in a document). > <xs:element name="relation" type="nml:RelationType" minOccurs="0" /> * relation: should be capitalized as Relation on line 23: Missing relation (lines 48-55): - canProvidePort (I assume that the implicit relations are not listed on purpose) > <xs:element name="duration" type="xs:duration" minOccurs="0" maxOccurs="1"/> LifeTime does not have a duration (only a end): LifeTime should not have an id attribute. Location should have an id attribute. Note: I have not yet looked at the cardinalities (minOccurs and maxOccurs) yet, and only reviewed about the first 100 lines, so this is an incomplete list of remarks. Freek

5 13

Fwd: [wg-all] OGF37: Call for Session Proposals
by Roman Łapacz 18 Jan '13

18 Jan '13

Do we want to have the nml session(s) there? Roman -- Treść oryginalnej wiadomości -- Temat: [wg-all] OGF37: Call for Session Proposals Data: Fri, 18 Jan 2013 12:22:28 +0100 Nadawca: OGF Events <events(a)ogf.org> Adresat: wg-all(a)ogf.org online form for session proposals: http://ogf.org/OGF37/cfp.php The OGF37 program committee seeks active participation from the community, and encourages the submission of session proposals that may include (but are not limited to) the following topics: Interop/ plugfest sessions Federated Identity and Delegation Data/Storage Identity Management and Virtual Organizations Production Infrastructure Interoperability Software Sustainability for Grids and Clouds Green IT, Energy Efficiency Inter-cloud interoperability and SLA management Networking for Distributed Computing Infrastructures Performance measurement of Grids and Clouds Science Clouds at large scales Grid and Cloud Security Distributed Desktop Grid and Volunteer Computing Emerging Distributed Infrastructure Campus Grids and Clouds Data Management in Grids and Clouds Federated Infrastrucutre OGF Chartered Group Sessions Birds of a Feather (BoF) Sessions In addition, there are opportunities for Plugfest Demonstrations and Tutorials. To Submit suggested proposal or session requests, please visit the OGF37 website at http://www.ogf.org/OGF37/ Note that you will need to log in (using your Gridforge username and password) to submit a Group Session request. OGF Session Types: OGF Chartered Groups and BoF Session: A session for an OGF Chartered Group to make progress according to the group's charter. Note that you will need to log in (using your Gridforge username and password) to submit a Group Session request. Birds of a Feather' (BoF): An informal discussion on a specific issue or subject, usually with the intent of forming a chartered group. OGF Area Meeting: A meeting called by the Area Directors of a particular OGF Area, usually a meeting with the chairs of the Chartered Groups in that Area. -- The wg-all mailing list is an umbrella list for all OGF mailing lists. If you are subscribed to any OGF mailing list, you will receive mails to wg-all. You can unsubscribe from this list on http://www.ogf.org/cgi-bin/perl/unsubscribe-wg-all.pl wg-all mailing list wg-all(a)ogf.org https://www.ogf.org/mailman/listinfo/wg-all

1 0

NML Schema document
by Jeroen van der Ham 17 Jan '13

17 Jan '13

Hello all, Some time ago Freek was kind enough to perform a thorough review of the schemas and the document. I believe that Roman and I have both addressed these comments. I have the feeling that the document is at this moment really at a point that we can send it to the board and have it open up for public comments. Please let me know what you think, if there are no serious concerns I will send this off this Thursday. Jeroen.

1 2

Review of the OWL schema
by Freek Dijkstra 17 Jan '13

17 Jan '13

Here is my review of the OWL schema: Discrepancy between names in document and OWL schema: * List should be OrderedList * endtime should be end * starttime should be start * labelvalue should be value * labelvalues should be values (I actually like endtime and starttime better, but the document and XSD schem use end and start) Missing items: * nml:canProvidePort relation * nml:parameter (likely not needed, just as nml:Relation is not needed) * nml:labelSwapping (DataProperty with domain: SwitchingService and range: boolean) * nml:noReturnTraffic (DataProperty with domain: Link and range: boolean) Spurious items (should be removed): * hasSource (use isSource instead) * hasSink (use isSink instead) * time (use start and end instead) The domains and/or ranges of the following Properties are different from what's allowed in the document: * hasInboundPort Domain should be NetworkObject (to allow future extensions) Range should be Union of Port and PortGroup * hasLabelGroup Domain is correct Range should be Union of LinkGroup and PortGroup * hasLink Domain should be Group (to allow future extensions) Range is correct * hasNode Domain should be NetworkObject (to allow future extensions) Range is correct * hasOutboundPort Domain should be NetworkObject (to allow future extensions) Range should be Union of Port and PortGroup * hasPort Domain should be Group (to allow future extensions) Range should be Union of Port and PortGroup * hasTopology Domain should be NetworkObject (to allow future extensions) Range is correct * implementedBy Domain should be NetworkObject (to allow future extensions) Range should be NetworkObject (to allow future extensions) * isSerialCompoundLink Domain is correct Range should be OrderedList * isSink Domain should be NetworkObject (there is an experimental feature from Node to Link) Range is correct * isSource Domain should be NetworkObject (there is an experimental feature from Node to Link) Range is correct * locatedAt Domain should be NetworkObject (e.g. Port is perfectly valid) Range is correct * providesLink Domain should be Service (to allow future extensions) Range is correct * providesPort Domain should be Service (to allow future extensions) Range is correct * item Domain is correct Range is correct (undefined) * adaptationfunction Domain is correct Range should be a URI * address Domain is correct Range should be undefined (typical use is a vCard object) * encoding Domain should be Union of Port, PortGroup, Link, and LinkGroup Range should be a URI * labeltype Domain is correct Range should be a URI * version Domain should be NetworkObject (to allow future extensions) Range should be a dateTime (from XMLSchema) The ranges of the following DataProperties are a URI, and thus should be described as a ObjectPoperty instead: * address (points to a vCard object) * adaptationfunction (points to an object in a NML extension schema) * encoding (points to an object in a NML extension schema) * labeltype (points to an object in a NML extension schema) For consistency in the document, consider swapping the order of domain and range in the following DataProperties: - existsDuring - hasInboundPort - hasLabel - hasLabelGroup - hasLink - hasNode - hasOutboundPort - hasPort - hasTopology - implementedBy - isAlias - isSerialCompoundLink - isSink - locatedAt Regards, Freek

3 3