[Nml-wg] Review of the XSD schema

[Roman Łapacz]

W dniu 2013-01-18 16:30, Aaron Brown pisze:
> 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.

OK. I can remove it from the xsd schema on Mon. What do you think Freek?

Roman

> Cheers,
> Aaron
>
>> Roman
>>
>>> Freek
>>
>