Stream: committers
Topic: repeating elements
Brian Postlethwaite (Feb 18 2017 at 05:55):
New message under repeating elements
This repeating element has no defined order
Not a fan of the extra text, should this be another icon in the flags column? (indicating the order is important)
(also, as an editor, how can we specify this importance?
Grahame Grieve (Feb 18 2017 at 16:17):
there's a new column 'Order Meaning'
Grahame Grieve (Feb 18 2017 at 16:17):
see in HumanName and Address
Grahame Grieve (Feb 18 2017 at 16:17):
I'm not of a fan either. But I'm not much of a fan of the underlying decision - if we don't assign an order an order in the spec you can't say anything about order in the profiles
Grahame Grieve (Feb 18 2017 at 16:23):
I don't see why you can't at least advise what the order is/should be, even if you can't enforce it
Grahame Grieve (Feb 18 2017 at 16:24):
it can't be a flag in the flag column because as soon as you give it a meaning, that's text. I did intend to give it some colour or something to help it stand out, but haven't got to that yet
Lloyd McKenzie (Feb 19 2017 at 20:04):
Issue is that profiles can't change the meaning of an instance. Asserting meaning to order of repetition would mean assigning meaning. If repetitions aren't assigned a meaning in the core spec and you want meaning in your profile, then add an extension (e.g. "priority number" or "last-changed-date" or whatever you need to allow the order to be made explicit)
Grahame Grieve (Feb 19 2017 at 20:16):
if the spec doesn't assign a meaning, I can still meaningfully say, 'well I provide the elements order x'
Josh Mandel (Feb 19 2017 at 20:17):
That's not assigning a *meaning* to the order. That's documenting your ordering practices.
Josh Mandel (Feb 19 2017 at 20:18):
Defining a meaning would be "when you see something in position 2, you should take it to be less important"
Josh Mandel (Feb 19 2017 at 20:18):
The line's really unclear to me though, between these.
Grahame Grieve (Feb 19 2017 at 20:29):
I think you're splitting hairs
Josh Mandel (Feb 19 2017 at 20:29):
Well, that was my point: I can't tell these apart!
Josh Mandel (Feb 19 2017 at 20:29):
If we don't allow one, how could we allow the other?
Grahame Grieve (Feb 19 2017 at 20:31):
well, I'm saying that there's a reason to allow both
Lloyd McKenzie (Feb 20 2017 at 04:16):
If you say "I will provide elements in this order" and the receiver is expected to interpret that as the meaning of the order, then they're being asked to extract meaning from the order that things appear in the spec. And if someone else defines a differing ordering strategy, they suddenly need different interface code for each recipient. Which would be a problem. There's no reason for a sender to document what order they're going to put elements in unless they expect the receiver to pay attention.
Grahame Grieve (Feb 20 2017 at 05:32):
you're once again falling into the trap of all or nothing
nicola (RIO/SS) (Feb 20 2017 at 05:35):
I think, the problem could be solved finally if we separate structure definition from profiling completely - separate concerns :)
nicola (RIO/SS) (Feb 20 2017 at 05:38):
This will make structure definition single responsible, and open ability to make profiles more expressive without coupling with structure, just focusing on constraints and invariants dsl
nicola (RIO/SS) (Feb 20 2017 at 05:40):
ups, wrong stream :( - excuse me
Lloyd McKenzie (Feb 20 2017 at 05:57):
@Grahame Grieve I don't understand the use-case for implementers to disclose the order in which they intend to express data that doesn't involve recipients paying attention to that knowledge. And if there's an expectation for implementers to pay attention (and thus for profiles to convey semantics), I don't see how you can believe that doesn't break things. I'm obviously missing something here, but I don't know what it is.
Last updated: Apr 12 2022 at 19:14 UTC
