On Jun 20, 2011, at 4:24 PM, Freek Dijkstra wrote:
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?
That's what I'd like. It'd be nice if outside folks could define their own attributes for the objects, and the objects would still be usable by someone who didn't know about the new attributes; those attributes would just be ignored. Cheers, Aaron
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Summer 2011 ESCC/Internet2 Joint Techs Hosted by the University of Alaska-Fairbanks http://events.internet2.edu/2011/jt-uaf