[Nml-wg] RNC questions

[Jason Zurawski]

Hi Freek;

On 6/20/11 2:40 PM, thus spake Freek Dijkstra:
> Hi Jason,
>
> Thanks for the quick feedback. As usual, it is much appreciated.
>
> 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? :)

>>> 3) The NML Group is -by it's current definition- recursive: A group is a
>>> NML NetworkObject, and a Group can contain NML NetworkObjects, thus
>>> including other groups. I have a problem with such recursive definitions
>>> in RNC. At least the validator complains about patterns defined later on
>>> in the document. Can't I do that, or am I just doing something wrong
>>> (I'm happy to provide offlist the URLs of RNC schema and example
>>> topology file I'm currently working on, so you can see the errors for
>>> yourself)
>>
>> I dont understand this question/problem.  Is this a problem of not being
>> able to validate something or is this just a perception problem where a
>> recursive definition personally bothers you?
>
> It is a problem parsing the RNC file. The error is:
> "Reference to undefined pattern BasePort."
> Apparently because BasePort is defined later then it used.
>
> 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.

>> Messages from the parser
>> (and which parser is being used/how it was invoked) would be helpful.
>>
>>> 4) In the current RNC schema, extensibility was ensured using the
>>> "anyElement" rule. E.g.
>>>       BasePortContent =
>>>         NetworkObject
>>>         &   element capacity { xsd:float }?
>>>         &   anyElement*
>>> Unfortunately, the validator complained about this.
>>
>> Was it a 'warning' or an 'error', both have different implications.
>
> An error.
>
>> This is one of the dangers/benefits to using anyElement.  In practice
>> define it as 'late' as possible in any rulset and the parser is smart
>> enough to choose the longest match (e.g. location) first.
>
> 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.

Thanks;

-jason