Proposal for an extension of ClassInFrameRef

[ue71603]

Addesses: #649

[Aurige]

Why a recursive definition here (we are within the ClassRefStructure definition) ?
And the result is a bit weird

[ue71603]

@Aurige Can't a member have member again? I think recursive is correc.t Or what would be your proposal?

[ue71603]

input from Christophe needed

[Aurige]

That's a ClassRefStructure inside a ClassRefStructure referred as Member ... but I'm not sure about what we wan't to say here, and waht is a member classs of a class ? Do you mean nested (for example a Quay inside a StopPlace) ? and if so, how would you make the difference between a ref (i.e a QuayRef) and the full object inclusion (Quay) ?

This recursion only allow to do things like this:

<netex:ClassRef nameOfClass="TOTO" use="required">
	<netex:MemberRef nameOfClass="TITI"/>
</netex:ClassRef>

[ue71603]

The original task is from Stefan. So I ask hiim:

In order to make a profile definition TypeOfFrame/ClassInFrameRef is an embedded way to describe a profile. What is currently lacking is the ability to describe the elements required in the profile.

If from this minimal definition a derived XML Schema (or Schematron) can be generated, every profile can be validated against an always up to date NeTEx upstream, without manual the manual labor of maintaining an extra XML Schema by hand (such as EPIP, Dutch, etc.)

@skinkie how deep do we want to go and Ref and objects?

[ue71603]

@Aurige epip used mixed=true in their profile. I know undo it... Was bad practice anyhow.

[skinkie]

At this moment the following is part of the EPIP example by @Aurige. The part that I don't understand is now the ClassInFrame nameOfClass is introduced. That entire nameOfClass does not exists.

<TypeOfFrame version="epip:1.0" id="epip:EU_PI_LINE_OFFER">
        <Name>Network and schedule data for a single line.</Name>
        <FrameClassRef nameOfClass="CompositeFrame"/>
        <classes>
                <ClassInFrameRef nameOfClass="DataManagedObject">Use Common definitions</ClassInFrameRef>
                <ClassInFrameRef nameOfClass="VersionFrame">Use Common definitions</ClassInFrameRef>
                <ClassInFrameRef nameOfClass="ResourceFrame">Use Common definitions</ClassInFrameRef>
                <!-- Specific -->
                <ClassInFrame nameOfClass="EU_PI_LINE_OFFER.SiteFrame-EU_PI_STOP">
                        <ClassRefType>all</ClassRefType>
                        <Mandatory>required</Mandatory>
                </ClassInFrame>

I think the question is if nameOfClass here should be something like:

<ClassInFrame nameOfClass="SiteFrame" typeOfFrameRef="epip:EU_PI_STOP" version="epip:1.0">

[Aurige]

I don't really remember that example (it must be pretty old, over 10 years, since NEPTUNE is not used any-more for quite long.. it was the equivalent of the UK TransXChange... so not NeTEx, but we did a mapping to NeTEx in 2013/14).
I agree that ClassInFrameRef can be a misleading name, it's initial intention was to refer a Class in the Frame...so more a ClassRefInFrame ... so initially no need for a ClassInFrame since the Class itself (Element in XSD) is really defined at XSD level. The ClassInFrame was added later (can't remember when/why... or maybe just in this set of commits ?)

[ue71603]

@skinkie do we need more levels? Or can you do with one?

[ue71603]

@skinkie does this fit you primary needs (when we don't implement full schematron).