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  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:
>>
>>>   
>>>     
>>>       
>>>       
>>>       
>>>       
>>>       
>>>     
>>>     
>>>   
>> Instead, I would suggest to use xs:all:
>>
>>>   
>>>     
>>>       
>>>       
>>>       
>>>       
>>>       
>>>     
>>>     
>>>   
>> 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:
>>
>>>   
>>>     
>>>       
>>>       
>>>       
>>>       
>>>       
>>>     
>>>     
>>>   
>> * 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):
>>
>>>       
>>>         
>>>         
>>>       
>> In fact there are four ways to represent implicit relations:
>>
>> 1.
>>
>> 
>>   My Device
>>   
>>     Somewhere
>>   
>> 
>>
>> 2.
>>
>> 
>>   My Device
>>   
>>     
>>       Somewhere
>>     
>>   
>> 
>>
>> 3.
>>
>> 
>>   My Device
>>   
>> 
>> 
>>   Somewhere
>> 
>>
>> 4.
>>
>> 
>>   My Device
>>   
>>     
>>   
>> 
>> 
>>   Somewhere
>> 
>>
>> 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:
>>
>> 
>>   My Device
>>   
>> 
>>
>> (thus without the  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:
>> -----------------
>>
>>>     
>> Remove line 32, as idRef is no longer used:
>>
>>>       
>> Remove minOccurs on line 40:
>> (perhaps the minOccurs should be listed elsewhere?)
>>
>>>     
>> 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).
>>
>>>       
>> * 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)
>>
>>>          
>> 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

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:

<!-- referencing and inheritance --> xs:all xs:choice

(2) attributes part of the group:

xs:all xs:choice <!-- referencing and inheritance -->

[..]

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

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

On Jan 17, 2013, at 7:32 AM, Roman Łapacz 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

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