Cart
[Home] [By Thread] [By Date] [Recent Entries]
In case I got it wrong a bit on the UBL mechanism for versions, in case anyone wants the most accurate facts about it, I hope G. Ken Holman doesn't mind if I reference his very up-to-date and timely mailing to UBL's Technical Committee today about it: http://lists.oasis-open.org/archives/ubl/200710/msg00014.html I'm not sure the status of this, I think the UBL TC have agreed the mechanism at least in principle if not in detail. Hopefully it does more (using transformations) towards compatibility for minor versions than a typical major version strategy does when it settles for incomplete compatibility. Best regards Stephen Green On 20/10/2007, Stephen Green <stephengreenubl@g...> wrote: > On 20/10/2007, Thomas Lord <lord@e...> wrote: > ... > > > To make Y the next version of X, we should be obligated to > > define two transforms: one that converts X to Y, the other > > for Y to X. > > Interesting that you are relying here on transformations. > > I may have misinformed about the example of how UBL is tackling > 'minor versioning': rather than use the 'any' they may be relying > on transformations but I have kept up with this too well lately. > > Either way, they have considered including transformations in > the process of validating - either for minor versions (not sure) or > for 'customized' versions. > > My own thinking is (quite simple I'm afraid) if you need to do > a transformation at all, either for processing or validating 'version Y' > rather than/as well as 'version X', then why not just strip out anything > in the 'any' extension point(s) (schema for A could designate where > such extension points can be at the top level - schema Y could add > more but below that top level) first. Then it will let you do both > validation and processing as if you were just dealing with 'version X'. > Two transformations at most would separate 'version X' and 'version Y > extension'. > > Imagination is left to decide what to do with the extensions. For example: > CDATA them and put them in a convenient string element in 'version X' > (perhaps one designated for the purpose with foresight in the 'version X' > schema) or if that doesn't work well maybe comment the extension out > so it doesn't interfere with validation as for version X or processing, or > if convenient put it in a separate instance but with a way to where it came > from of course. None of this requires a major version change (which I'd > regard as one which loses schema compatibility with the previous version). > > > > > So, the solution is that programs shouldn't simply check > > inputs against a schema, if they want an extensible input > > language. Rather, programs should first transform inputs > > to a familiar type, then check those, and optionally transform > > outputs to some externally requested type. > > So yes I agree that you can avoid problems with versioning if you are willing > to rely on transformations but > 1. I don't think that means you have to drop the possibility of such versions > being 'backwards or forward compatible' with previous versions > 2. I think it means use of 'any' extension points is even safer because the > transformation(s) can separate it in some convenient way (just like the > way email clients separate attachments perhaps but perhaps some more > standardization of metadata might help make things as easy as SMTP). > > > > > With that basic rule, one can begin to define very clean > > ways to handle "unrecognized -- from some future version" > > fields. Also, the XML structure of a language is made > > orthogonal to the versioning of the language: different > > versions can have completely different strict schema. > > > > -t > > http://www.dasht-exp-1a.com > > > > -- Stephen Green Partner SystML, http://www.systml.co.uk Tel: +44 (0) 117 9541606 http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
