Jason Zurawski wrote:
My personal opinion would be to use '&' always, and avoid the ordering
attempt since I still do not believe a 'list' element is required.
I'm fine eliminating the list element, but -to me- this is unrelated of
the ordering in RNC files.
In fact, I'm a bit confused now. We introduced explicit lists late
October, after you commented that XML has no inherent order. I can't
find a on-list quote, but this is what you wrote off-list:
E.g. XML is not ordered (you cannot be sure that the children will
come out in any order). Most parsers respect 'document order', but
this is not in the spec.
The list element was introduced after because of this note. (We later
decided on using "next" relations instead of a numbered list).
Why do you think a 'list' element is not required?
Correct, XML has no inherent order which is all the more reason to not
use the ',' as a joining element. Why try to require ordering that is
hard to achieve? :)
Because network paths are ordered...
(However I don't think that elements in an XML file should be ordered in
a particular way -- e.g. latitude and longitude can go in any order --
these are two unrelated issues to me. Sorry to spell out the obvious
here; I'm just trying to make sure we're on the same par here -- I think
we are.)
I'll play a bit more, if I can't find a solution, I'll find some
RNC-users mailing list, or contact you off-list.
Good luck finding a list on that topic, I would assume that even if you
could find one it would not be very active (RNC is not the most popular
of schema languages). You are better directing your comments here, and
someone who has used this for NMC/NML/NM work can most likely answer.
The perfSONAR-dev list is also a good candidate.
Thanks for the offer. I may take up on it ;)
OK, so you suggest to keep the anyElements. I'll see if that works in my
validator, or move to another validator.
I suggest you think about if they make sense - if you can't think of a
situation where an arbitrary blob of XML that is not defined in some
other schema is required, then you won't need them. AnyElement was
introduced for situations where some parsing code wouldn't care about
XML inside of some target element. E.g. A data element with some
structure that you didn't want to dig into, but you knew had to be well
formed XML.
If this is common in the NML work, its a good fit. If everything is
always well defined (e.g. has a schema associated with it) you don't
need it.
If you have any advice here, please tell.
For me this is about backward compatibility. Either we make the current
schema strict and later revision looser by adding more allowed elements.
Or we make the the current schema loose and later revisions more strict.
I presume that the second approach is more common, since that allows a
XML to validate against both the old and the new schema. Thus: add
wildcards (in RNC: "anyElement" rules) for the current schema.
Is this your thinking as well?