This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

UBL paper on the subject

From HL7Wiki
Jump to navigation Jump to search

note from charlie mccay:

This is an old thread, and my apologies for not picking it up at the time. If the topic is now closed in UBL I would be interested to hear where the conclusion is documented, and if not I would be interested in tracking/contributing to the discussion. I would be happy to provide more detailed comments on the paper referenced here if that is still relevant.

There is ongoing debate in HL7 on this subject, with the current schema design having all HL7 defined language versions in the same namespace, and extensions in foreign namespaces.

There has been strong pushback against using different namespaces for minor (and not-so-minor) version changes. This is for a number of reasons:

Having a number of different namespaces in a single instance that track the version where an information item was added is ugly (thus error-inducing) for those that are not interested in the earlier versions.

Writing namespace-agnostic code is non-trivial, and so to promote code/transform reuse between versions and related models it is easier not to have to change the namespace.

There is a real reluctance to do pre-processing transforms -- with systems working on high volumes and tight performance targets, this is an additional overhead that they do not feel that they can afford.


For these reasons we are looking to follow the XSLT approach of having version attributes to indicate the nodes that conform to more recent versions and can safely be ignored by processors that are only aware of older version structures. Because the HL7 schema are developed in a model driven architecture, the management of names to avoid clashes is done in the modeling stage.

All the best

Charlie

Charlie McCay, charlie@RamseySystems.co.uk (co-chair HL7 Implementation Technology Special Interest Group) Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel +44 1743 232278 / +44 7808 570172 skype: charliemccay



Original Message-----

From: Ann Wrightson [1] Sent: 21 August 2007 14:20 To: Charlie McCay Subject: FW: Discussion of namespaces for minor versioning

Charlie,

Would you be able to respond to Jon as below, from your versioning work? The timing is even OK to refer it to a discussion at the WGM, if you felt it was worthwhile.

Best regards,

Ann W.



Original Message-----

From: jon.bosak@sun.com [2] Sent: 21 August 2007 13:50 To: Ann Wrightson; dallen@acord.org; danielgr@itis.com; plb@itst.dk; scayron@acord.org Cc: abcoates@mileywatts.com; gkholman@CraneSoftwrights.com; grimleymj@npt.nuwc.navy.mil; harvey@eccnet.com; tmcgrath@portcomm.com.au; zarella@xml-factor.com Subject: Discussion of namespaces for minor versioning

Hello XML experts,

The UBL TC has been considering a controversial proposal from Ken Holman to use namespaces for minor versioning. We find Ken's proposal attractive, but several TC members harbor doubts about the thought of using namespaces this way. The TC has therefore asked me to begin a brief discussion of the issue among the most concerned UBL TC members and a few notable XML experts whom we hope might be prevailed upon to lend us their opinions, the issue of versioning being of potential interest to other XML-based standards efforts such as HL7 and ACORD. We wish to resolve this issue at the 24 September UBL TC plenary in Stockholm if possible, so the discussion should be of relatively brief duration.

If you would be so kind as to help us out with this (and we will certainly understand if you don't have the time), please see Ken's paper on "UBL 2.0 customizations, extensions, versions, validation and interchange" at

  http://www.oasis-open.org/committees/document.php?document_id=23654

You'll note that the namespace-based versioning proposal is in Section 9 of this document (page 26 in the US letter PDF version).

Two key understandings before we start:

- "Versioning" in this context refers to *minor* versions, which
  by definition in UBL are versions that simply add optional
  constructs (or make previously required constructs optional).
- Ken's proposal is *not* that the namespace of an entire schema
  be changed in the new minor version, but rather that a new
  minor-version-specific namespace be assigned only to
  newly-introduced elements.

To kick off the discussion, I'll offer an initial not-very-expert take based on a quick re-reading of Section 9. The misgivings expressed in the TC so far spring from a concern that namespace-based versioning will break deployed software. But it's clear from the proposal itself that it assumes the transform-before-validate processing model described in Section 8 of the paper. It seems to me, therefore, that an evaluation of namespace-based minor versioning will have to include an evaluation of the transform-before-validate approach, and in particular of Ken's assertion (which appears to be borne out by recent W3C work) that "only a transform-before-validate processing model will allow a system based on validation to implement forwards-compatible support for evolving XML schemas" (last sentence of Section 9.5). If that's true, then it seems to me that Ken's proposal for namespace-based versioning makes a lot of sense.

My question for Ken would be why we can't get the same results in UBL from name-based transformation (Section 7.2), given that all elements in UBL are global. (Ken is on vacation at the moment and his computer is in for repair, so I don't expect an answer to this right away, but I thought I'd toss it into the pot.)

Jon