|
|
|
Jeroen van der Ham: 11/30/2012 7:53 AM EST
|
| |
Action: |
Update
Closed set to 11/30/2012
Status changed from Last Call - Reject to Rejected
|
|
|
Jason Zurawski: 08/16/2012 7:36 AM EDT
|
| |
Comment: |
Agree on the reject - inverse is a bit complicated given we get full functionality with a single 'direction' (e.g. single linked list w/ next is just
as powerful as a double linked that features 'previous').
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 08/08/2012 10:45 AM EDT
|
| |
Comment: |
I don't see a problem with implementing reverse relations in a data structure for speed or other reasons.
I think that the drawbacks of inverse relations in a protocol (ie. forcing ALL implementations to implement them) outweight the benefits (easier to
automatically translate the schema into code for those implementations that like inverse relations in their internal datastructures).
|
| |
Action: |
Update
|
|
|
Jeroen van der Ham: 08/08/2012 10:22 AM EDT
|
| |
Comment: |
Sorry for the late comment.
We're currently using models in the GEYSERS and NOVI project where the information models have been (automatically) translated into Java objects. We
have noticed there that it is often desirable to do have the inverse relations. It often makes it more natural for programming.
|
| |
Action: |
Update
|
|
|
Freek Dijkstra: 08/08/2012 10:01 AM EDT
|
| |
Action: |
Update
Status changed from Last Call to Last Call - Reject
|
|
|
Freek Dijkstra: 07/30/2012 7:59 AM EDT
|
| |
Comment: |
I propose we REJECT this proposal for NML version 1.
During discussion on the mailing list, there were concerns over complicating the parser, while the most compelling use case (inability to use idRef in
a parent XML element) has been covered in artf6553). I have not seen enough interest after that to pursue this at the moment.
|
| |
Action: |
Update
Status changed from Under discussion to Last Call
|
|
|
Freek Dijkstra: 04/02/2012 10:08 AM EDT
|
| |
Comment: |
I have two questions about this proposal
1. Are A --(R)--> B and B --(R')--> A (with R' the inverse relation of R) exactly equivalent? If they are
equivalent, can they be used interchangably, or are there some additional rules when they should or should not be used?
For example, the inverse relation of <nml:Relation type="next"> is <nml:Relation type="previous">. This was voted down at OGF 32, but I presume that
this proposal reverts that decision.
For example, would the following be allowed?
<nml:Link id="urn:ogf:network:example.net:2012:linkZ">
<nml:Relation type="isSerialCompoundLink">
<!-- this is a list -->
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkA"/>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
<nml:Relation type="previous">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
</nml:Relation>
<nml:Relation type="next">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
</nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
</nml:Relation>
</nml:Link>
If this is not allowed, why not, and what are the exact rules why this is not allowed, while e.g. hasSource can be used.
2. Currently some relations are one-to-many, such as isSerialCompoundLink. How should the inverse relation be written in XML?
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
<nml:Relation type="next">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
</nml:Relation>
<nml:Relation type="partofSerialCompoundLink">
<nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
</nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
<nml:Relation type="next">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
</nml:Relation>
<nml:Relation type="partofSerialCompoundLink">
<nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
</nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
<nml:Relation type="partofSerialCompoundLink">
<nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
</nml:Relation>
</nml:Link>
Or should there be some grouping around the list?
(which is in fact what Jeroen suggested at OGF32, but was voted down at that time)
<nml:List>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkA">
<nml:Relation type="next">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkA"/>
</nml:Relation>
</nml:List>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkB">
<nml:Relation type="next">
<nml:Link nm:idRef="urn:ogf:network:example.net:2012:linkC"/>
</nml:Relation>
</nml:Link>
<nml:Link nm:id="urn:ogf:network:example.net:2012:linkC">
<nml:Relation type="isSerialCompoundLink">
<nml:Link id="urn:ogf:network:example.net:2012:linkZ"/>
</nml:Relation>
</nml:List>
|
| |
Action: |
Update
|
|
|
|
