Skip to content

Alternative mechanism?

canterburym requested to merge draft/mc/103707_identifiers into draft/TS103707/adding_a_format_for_identifiers

I've used an anonymous choice in the original sequence; this allows each element in the existing sequence to be either an unqualified string (i.e. as now) or a new-style structure.

I've added example_new_identifier.xml in the examples folder to show how this works. It's based on the original simple example, but now the target has both a qualified and unqualified identifier, and the non-target has only a qualified identifier.

Things I like about this:

  • A message built against the old schema is still valid, and still means the same thing
  • An implementation built against the new schema can interoperate with an old one by only choosing to use unqualified identifiers
  • We don't change anything in the MessagingParty type
  • It sort of feels right; we are adding a new way of describing identifiers, but keeping it in the same place.

Things I don't like about this:

  • It uses an anonymous choice; I've actually made drafting rules against doing this in other specs!
  • It relaxes the minOccurs=1 for the elements within the list i.e. you could now have an empty list. I'll see if I can fix this, but if not we can introduce the requirement in prose. now fixed!

As an aside - I noticed the automated testing wasn't checking the examples in 707 against the schema. So I've also changed the testing config to fix this. I think we should do this whatever we do with the CR, but if you don't mind having it as part of the CR it saves me from having to remember to do it elsewhere!

EDIT: I should also say that I haven't spent any time thinking about what goes in the new qualified structure, so it doesn't follow 120 Annex C. We can chat about that separately; this was really just to see if you liked the alternative way of getting any structure in to the identifier list.

What do you think?

Edited by canterburym

Merge request reports