[Nml-wg] Review of the XSD schema

[Aaron Brown]

On Jan 17, 2013, at 7:32 AM, Roman Łapacz <romradz at 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-order-any-number-of-times
>> [...]
>> 
>>>> 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
> 
>