W dniu 2013-01-18 16:30, Aaron Brown pisze:
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.
OK. I can remove it from the xsd schema on Mon. What do you think Freek? Roman
Cheers, Aaron
Roman
Freek