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
Hi Freek, Thanks for the comments. I'll look at them closer in 2013 :) (next week). Happy New Year, Roman W dniu 2012-12-28 02:34, Freek Dijkstra pisze: > 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 > _______________________________________________ > nml-wg mailing list > nml-wg@ogf.org > https://www.ogf.org/mailman/listinfo/nml-wg
On 28-12-2012 13:23, Roman Łapacz wrote:
Thanks for the comments. I'll look at them closer in 2013 :) (next week).
Have a great new years eve. I was wondering this morning if the schema should make a distinction between a reference and a "inline" object description. I now think there is no difference in syntax: In both cases it is a object, with id, and optional other attributes and child elements. If you like I can go through it in more detail. Unfortunately, I'm not well versed enough to e.g. understand the difference between
<xs:complexType name="NetworkObject"> <xs:sequence> <xs:element name="relation" type="nml:RelationType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="parameter" type="nml:ParameterType" minOccurs="0" maxOccurs="unbounded" /> <!-- .... --> </xs:sequence> <!-- .... --> </xs:complexType>
and
<xs:complexType name="NetworkObject"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="relation" type="nml:RelationType" /> <xs:element name="parameter" type="nml:ParameterType" /> </xs:sequence> </xs:complexType>
Freek
Hi, Freek, I'll respond directly your question/comments on Mon (in few minutes I have to leave my office). Shortly, I've updated the XSD schema including your comments. Very important change is that relations are defined separately for each elements (see XXXRelationType definitions). This offers more precise assignment of relations to elements as well as better distinction between implicit and explicit relations. Also I've updated the XML examples to be sync with the current version of nml-base. Please, generate new pdf that will include the changes. btw, please, take a look at the type attributes of Label and LabelGroup. They are different in the UML diagram and descriptions in the relevant subsections (type vs labeltype). Cheers, Roman W dniu 2012-12-28 02:34, Freek Dijkstra pisze: > ------------------------------ > > * Where does it specify that all NML descriptions should start with > nml:Topology as the root element? There is no such strict imitation. > > * 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 > _______________________________________________ > nml-wg mailing list > nml-wg@ogf.org > https://www.ogf.org/mailman/listinfo/nml-wg
Hi, Have these concerns been addressed yet? Jeroen. On 27 Dec 2012, at 15:34, Freek Dijkstra <freek.dijkstra@sara.nl> wrote:
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 _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
W dniu 2013-01-15 19:56, Jeroen van der Ham pisze: > Hi, > > Have these concerns been addressed yet? Yes. The problem (hmm, maybe it's not a problem) I have with xs:sequence. Unfortunately I can not use xs:all in all places I would like. Trying to change that I was fighting with validation and ended up with big mess in the schema and still validation errors. For the time being I propose to have in few places this forced sequences. In the future I'll try to change that but this may influence on many already existing XSD structures in the schema. Roman > > Jeroen. > > On 27 Dec 2012, at 15:34, Freek Dijkstra <freek.dijkstra@sara.nl> wrote: > >> 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 >> _______________________________________________ >> nml-wg mailing list >> nml-wg@ogf.org >> https://www.ogf.org/mailman/listinfo/nml-wg > _______________________________________________ > nml-wg mailing list > nml-wg@ogf.org > https://www.ogf.org/mailman/listinfo/nml-wg
W dniu 2012-12-28 02:34, Freek Dijkstra pisze:
General questions and remarks: ------------------------------
* Where does it specify that all NML descriptions should start with nml:Topology as the root element?
It's not specified. No need.
* 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 theory the use of xs:all is allowed inside xs.complexType but when I run validation for it in this case (based on Xerces) it gets crazy: Error at (file nmlbase.xsd, line 149, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 196, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 107, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 235, char 46): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 287, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 323, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 359, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 416, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 460, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 494, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file nmlbase.xsd, line 523, char 47): all compositor that is part of a complex type definition must constitute the entire content of the definition Error at (file stdin, line 7, char 45): attribute 'id' is not declared for element 'Topology' Error at (file stdin, line 7, char 45): attribute 'version' is not declared for element 'Topology' Error at (file stdin, line 17, char 77): attribute 'id' is not declared for element 'Link' Error at (file stdin, line 17, char 77): attribute 'encoding' is not declared for element 'Link' Error at (file stdin, line 21, char 57): attribute 'id' is not declared for element 'Node' Error at (file stdin, line 37, char 69): attribute 'id' is not declared for element 'Topology' Error at (file stdin, line 39, char 77): attribute 'id' is not declared for element 'BidirectionalPort' Error at (file stdin, line 40, char 71): attribute 'id' is not declared for element 'Port' Error at (file stdin, line 41, char 70): attribute 'id' is not declared for element 'Port' It does not like the structure: <xs:complexType name="..."> <xs:complexContent> <xs:extension base="nml:NetworkObject"> Besides xs:all seems to be very limited. It can not contain xs:group, xs:choice, xs:sequence.
* 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)
I updated Relations. Now there is clear distinction between implicit and explicit ones.
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?
Experimental relations I propose to put in a separate namespace. This should work.
Specific remarks: -----------------
<xs:attribute name="idRef" type="xs:anyURI" use="optional"/>
Remove line 32, as idRef is no longer used:
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). (updated version of the xsd schema is already uploaded in the repo) Roman
On 16-01-2013 11:57, Roman Łapacz wrote:
* Where does it specify that all NML descriptions should start with nml:Topology as the root element?
It's not specified. No need.
Should we put this in the document somewhere? If so, where?
* 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. [...] Instead, I would suggest to use xs:all:
(FYI: xs:all allows any order of the child elements; the current XSD schema uses xs:sequence which dicates the order).
In theory the use of xs:all is allowed inside xs.complexType but when I run validation for it in this case (based on Xerces) it gets crazy:
Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick. I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-... Out of curiousity, what happens in these cases: (1) Attributes move to the start of the complexType:
<xs:complexType name="NetworkObject"> <xs:attribute name="id" type="xs:anyURI" use="optional"/> <xs:attribute name="idRef" type="xs:anyURI" use="optional"/> <!-- referencing and inheritance --> <xs:attribute name="version" type="xs:unsignedInt" use="optional"/> <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: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> </xs:all> </xs:complexType>
(2) attributes part of the group:
<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: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> <xs:attribute name="id" type="xs:anyURI" use="optional"/> <xs:attribute name="idRef" type="xs:anyURI" use="optional"/> <!-- referencing and inheritance --> <xs:attribute name="version" type="xs:unsignedInt" use="optional"/> </xs:all> </xs:complexType>
[..]
Besides xs:all seems to be very limited. It can not contain xs:group, xs:choice, xs:sequence.
That's true for XSD 1.0: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-contentModel But for XSD 1.1, this limitation is lifted: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#declare-contentModel Apparently, Xerces only supports XSD 1.0.
I updated Relations. Now there is clear distinction between implicit and explicit ones.
Ah, After I send this mail, I realized it is possible to eliminate the difference, and started to become in favour of that solution. :) I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there.
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong).
It is not mentioned in the document nor OWL schema. Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id? I'm fine, but that kind of info ought to be in the document. Freek
W dniu 2013-01-17 02:13, Freek Dijkstra pisze:
On 16-01-2013 11:57, Roman Łapacz wrote:
* Where does it specify that all NML descriptions should start with nml:Topology as the root element? It's not specified. No need. Should we put this in the document somewhere?
I don't think so. A subset of nml elements may be used be some applications and I can imagine that nml:Topology is not needed.
If so, where?
* 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. [...] Instead, I would suggest to use xs:all: (FYI: xs:all allows any order of the child elements; the current XSD schema uses xs:sequence which dicates the order).
In theory the use of xs:all is allowed inside xs.complexType but when I run validation for it in this case (based on Xerces) it gets crazy: Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick.
I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-...
Out of curiousity, what happens in these cases:
(1) Attributes move to the start of the complexType:
<xs:complexType name="NetworkObject"> <xs:attribute name="id" type="xs:anyURI" use="optional"/> <xs:attribute name="idRef" type="xs:anyURI" use="optional"/> <!-- referencing and inheritance --> <xs:attribute name="version" type="xs:unsignedInt" use="optional"/> <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: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> </xs:all> </xs:complexType>
(2) attributes part of the group:
<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: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> <xs:attribute name="id" type="xs:anyURI" use="optional"/> <xs:attribute name="idRef" type="xs:anyURI" use="optional"/> <!-- referencing and inheritance --> <xs:attribute name="version" type="xs:unsignedInt" use="optional"/> </xs:all> </xs:complexType>
Attributes have to be at the end of xs:complexType and can not be inside xs:all
[..]
Besides xs:all seems to be very limited. It can not contain xs:group, xs:choice, xs:sequence. That's true for XSD 1.0: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-contentModel
But for XSD 1.1, this limitation is lifted: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#declare-contentModel
Apparently, Xerces only supports XSD 1.0.
Yes (for validation I use StdInParse based on Xerces-C++). We need something for validation. Xerces seems to be the best choice (correct me if I'm wrong or you have also a good alternative). We should assume that implementations may use automatic schema validation for nml structures so we have to run validation with a well-known tool/lib as well (and then announce that e.g. the NML schema v1 is validated with Xerces).
I updated Relations. Now there is clear distinction between implicit and explicit ones.
Ah, After I send this mail, I realized it is possible to eliminate the difference, and started to become in favour of that solution. :)
I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there.
Now it should be there. Please, check it.
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). It is not mentioned in the document nor OWL schema.
Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id?
Yes. I clearly remember that we agreed to keep it. We prefer to use id but IdRef for references should be allowed as well.
I'm fine, but that kind of info ought to be in the document.
Yes Roman
Freek
On 17-01-2013 12:07, Roman Łapacz wrote:
* Where does it specify that all NML descriptions should start with nml:Topology as the root element? It's not specified. No need. Should we put this in the document somewhere?
I don't think so. A subset of nml elements may be used be some applications and I can imagine that nml:Topology is not needed.
OK.
Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick.
I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-... [...]
Apparently, Xerces only supports XSD 1.0.
Yes (for validation I use StdInParse based on Xerces-C++).
OK, let's use XSD 1.0. Apparently is no simple method to allow any order of child elements with XSD 1.0. Too bad! :(. (Feel free to read the above page, perhaps you find a different answer, but I can't see it, expect for one convoluted solution which I'm sure is not what we want).
I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there.
Now it should be there. Please, check it.
Yes. thanks!
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). It is not mentioned in the document nor OWL schema.
Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id?
Yes. I clearly remember that we agreed to keep it. We prefer to use id but IdRef for references should be allowed as well.
So keep both, noting that there is no difference between them and they can be used interchangeably without loss of meaning in NML 1.0? Note that RDF can not make a distinction between id and idRef (because it does not use either of them), so if we ever decide to give a different meaning between id and idRef, that can not be codified in RDF (which I think is bad). That said, I don't remember that we wanted to keep them (http://redmine.ogf.org/issues/50 says we "shelve it") But I rather add it now and move on instead of starting the discussion now. So let's add idRef to the document as completely equivalent to id, with the note that future versions may make a distinction. Is that acceptable to all? Freek
W dniu 2013-01-17 13:17, Freek Dijkstra pisze:
On 17-01-2013 12:07, Roman Łapacz wrote:
* Where does it specify that all NML descriptions should start with nml:Topology as the root element? It's not specified. No need. Should we put this in the document somewhere? I don't think so. A subset of nml elements may be used be some applications and I can imagine that nml:Topology is not needed. OK.
Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick.
I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-... [...]
Apparently, Xerces only supports XSD 1.0. Yes (for validation I use StdInParse based on Xerces-C++). OK, let's use XSD 1.0.
Apparently is no simple method to allow any order of child elements with XSD 1.0. Too bad! :(.
(Feel free to read the above page, perhaps you find a different answer, but I can't see it, expect for one convoluted solution which I'm sure is not what we want).
The found issues/limitation while doing the schema irritated me a lot. I'll come back to it soon to find constructions I like.
I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there. Now it should be there. Please, check it. Yes. thanks!
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). It is not mentioned in the document nor OWL schema.
Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id? Yes. I clearly remember that we agreed to keep it. We prefer to use id but IdRef for references should be allowed as well. So keep both, noting that there is no difference between them and they can be used interchangeably without loss of meaning in NML 1.0?
Note that RDF can not make a distinction between id and idRef (because it does not use either of them), so if we ever decide to give a different meaning between id and idRef, that can not be codified in RDF (which I think is bad).
That said, I don't remember that we wanted to keep them (http://redmine.ogf.org/issues/50 says we "shelve it")
But I rather add it now and move on instead of starting the discussion now. So let's add idRef to the document as completely equivalent to id, with the note that future versions may make a distinction.
Aaron, correct me if I'm wrong, you proposed to keep idRef as an alternative (we had a long discussion with no final decision and decided to leave it as is and come back to it later).
Is that acceptable to all?
fine by me Roman
Freek
On Jan 17, 2013, at 7:32 AM, Roman Łapacz <romradz@man.poznan.pl> wrote:
W dniu 2013-01-17 13:17, Freek Dijkstra pisze:
On 17-01-2013 12:07, Roman Łapacz wrote:
* Where does it specify that all NML descriptions should start with nml:Topology as the root element? It's not specified. No need. Should we put this in the document somewhere? I don't think so. A subset of nml elements may be used be some applications and I can imagine that nml:Topology is not needed. OK.
Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick.
I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-... [...]
Apparently, Xerces only supports XSD 1.0. Yes (for validation I use StdInParse based on Xerces-C++). OK, let's use XSD 1.0.
Apparently is no simple method to allow any order of child elements with XSD 1.0. Too bad! :(.
(Feel free to read the above page, perhaps you find a different answer, but I can't see it, expect for one convoluted solution which I'm sure is not what we want).
The found issues/limitation while doing the schema irritated me a lot. I'll come back to it soon to find constructions I like.
I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there. Now it should be there. Please, check it. Yes. thanks!
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). It is not mentioned in the document nor OWL schema.
Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id? Yes. I clearly remember that we agreed to keep it. We prefer to use id but IdRef for references should be allowed as well. So keep both, noting that there is no difference between them and they can be used interchangeably without loss of meaning in NML 1.0?
Note that RDF can not make a distinction between id and idRef (because it does not use either of them), so if we ever decide to give a different meaning between id and idRef, that can not be codified in RDF (which I think is bad).
That said, I don't remember that we wanted to keep them (http://redmine.ogf.org/issues/50 says we "shelve it")
But I rather add it now and move on instead of starting the discussion now. So let's add idRef to the document as completely equivalent to id, with the note that future versions may make a distinction.
Aaron, correct me if I'm wrong, you proposed to keep idRef as an alternative (we had a long discussion with no final decision and decided to leave it as is and come back to it later).
Is that acceptable to all?
fine by me
My proposal was to get rid of it completely, and just use a relation extension in the future. That way we don't have core accepted syntax that changes semantics when we do add references in. Cheers, Aaron
Roman
Freek
W dniu 2013-01-18 16:30, Aaron Brown pisze:
On Jan 17, 2013, at 7:32 AM, Roman Łapacz <romradz@man.poznan.pl> wrote:
W dniu 2013-01-17 13:17, Freek Dijkstra pisze:
On 17-01-2013 12:07, Roman Łapacz wrote:
> * Where does it specify that all NML descriptions should start with > nml:Topology as the root element? It's not specified. No need. Should we put this in the document somewhere? I don't think so. A subset of nml elements may be used be some applications and I can imagine that nml:Topology is not needed. OK.
Ok.... well, I guess this mostly proves that I am indeed not fluent in XSD. What I was trying to accomplish is to allow any order of child elements, and thought that xs:all did the trick.
I actually was inspired by the answes to this post: http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-... [...]
Apparently, Xerces only supports XSD 1.0. Yes (for validation I use StdInParse based on Xerces-C++). OK, let's use XSD 1.0.
Apparently is no simple method to allow any order of child elements with XSD 1.0. Too bad! :(.
(Feel free to read the above page, perhaps you find a different answer, but I can't see it, expect for one convoluted solution which I'm sure is not what we want). The found issues/limitation while doing the schema irritated me a lot. I'll come back to it soon to find constructions I like.
I'm curious to your solution. Did you push it to the git repository? I only see Jeroen's commit of Jan 15 there. Now it should be there. Please, check it. Yes. thanks!
I keep idRef as we agreed to still support it (as an option; correct me if I'm wrong). It is not mentioned in the document nor OWL schema.
Do you propose to change these documents too, and explicitly allow idRef with the note that it should be regarded as completely equivalent to id? Yes. I clearly remember that we agreed to keep it. We prefer to use id but IdRef for references should be allowed as well. So keep both, noting that there is no difference between them and they can be used interchangeably without loss of meaning in NML 1.0?
Note that RDF can not make a distinction between id and idRef (because it does not use either of them), so if we ever decide to give a different meaning between id and idRef, that can not be codified in RDF (which I think is bad).
That said, I don't remember that we wanted to keep them (http://redmine.ogf.org/issues/50 says we "shelve it")
But I rather add it now and move on instead of starting the discussion now. So let's add idRef to the document as completely equivalent to id, with the note that future versions may make a distinction.
Aaron, correct me if I'm wrong, you proposed to keep idRef as an alternative (we had a long discussion with no final decision and decided to leave it as is and come back to it later).
Is that acceptable to all? fine by me My proposal was to get rid of it completely, and just use a relation extension in the future. That way we don't have core accepted syntax that changes semantics when we do add references in.
OK. I can remove it from the xsd schema on Mon. What do you think Freek? Roman
Cheers, Aaron
Roman
Freek
On 18-01-2013 16:47, Roman Łapacz wrote:
My proposal was to get rid of it completely, and just use a relation extension in the future. That way we don't have core accepted syntax that changes semantics when we do add references in.
OK. I can remove it from the xsd schema on Mon. What do you think Freek?
I agree with Aaron. Freek
participants (5)
-
Aaron Brown -
Freek Dijkstra -
Freek Dijkstra -
Jeroen van der Ham -
Roman Łapacz