[Nml-wg] RNC questions

[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?

>> 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.

> 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.

Regards,
Freek