December 2012 - nml-wg - lists.ogf.org

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

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

Missing items in nml-base
by Freek Dijkstra 27 Dec '12

27 Dec '12

Hi all, First of all -- enjoy the end of year festivities! I just reviewed the OWL schema (see my next email) and found a few items present in the OWL schema which are missing in the document: * next relation * ListItem object (only used in OWL for OrderedLists) * item relation (only used in OWL for OrderedLists) Should we describe these? FYI, there was also one incorrectly labeled attribute: * set of a LabelGroup in figure 1 (should be "values") This is a simple fix. Freek

1 0

Definitions for relations
by Jeroen van der Ham 18 Dec '12

18 Dec '12

Hi, I've just committed an updated version of the NML Schema document. This includes earlier changes from Freek. I have also committed definitions for several relations. There is one that I want to check with you: The \emph{Label} assigned to this \emph{Port} is the technology label that the traffic through this \emph{Port} has been assigned. This \emph{Label} is used to distinguish the \emph{Port} in a \emph{PortGroup}, or to define the traffic flow through a \emph{SwitchingMatrix}. Is that correct? For others I have added some text, or removed the TODO because the definition was already in the first description of the relation, and it is a too simple definition to expand further. Jeroen.

1 0

Review of RDF
by Freek Dijkstra 14 Dec '12

14 Dec '12

Jeroen, You asked me to review the RDF file. A small question to start with: > <http://schemas.ogf.org/nml/2012/10/base> rdf:type owl:Ontology ; > rdfs:label "NML Schema" . Should this URI include the hash (#) or not? I forgot... Freek

2 2

Meeting today
by Jeroen van der Ham 13 Dec '12

13 Dec '12

Hi, We have another call later today at the usual time and place: UTC 16:00 - CET 17:00 - Eastern 11:00 - Pacific 8:00. Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Agenda: - Finalize the NML Schema draft. Jeroen.

1 1

Reference subsection
by Freek Dijkstra 10 Dec '12

10 Dec '12

Hi all, and Jeroen and Roman in particular, I just pushed some changes to the subsection describing References, adding small diagram showing all cardinalities, and making a distinction between allowed and defined relations. Please check if there are no errors or omissions. Next up: I think most relations needs a slightly better descriptive text. Right now most relations just say there may be a relation between two objects, but don't tell what that relation means. Jeroen, commit 21dcef59 also closes the open artifact on inverse multiplexing adaptation functions. I think the existing text was already good, but I moved it from a footnote in De-Adaptation to the Adaptation description. Regards, Freek

3 3

Call today
by Jeroen van der Ham 06 Dec '12

06 Dec '12

Hi, My apologies for the very late reminder, but we have a call today at the usual time and place: UTC 16:00 - CET 17:00 - Eastern 11:00 - Pacific 8:00. Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145 Jeroen.

2 3

Source code repository
by Jeroen van der Ham 04 Dec '12

04 Dec '12

Hi all, We've moved the source-code repository over to git now. I've just synced up the subversion and git repositories, so no work should be lost. Get the new source code of the document with the following command: git clone gitosis@redmine.ogf.org:standards/infrastructure-area/nml-wg.git (This needs your public key on Redmine, you can add it at https://redmine.ogf.org/my/public_keys) As far as I know there is no way to transition your current codebase from SVN to git. Jeroen.

1 0