Re: [xml-dev] The <any/> element: bane of security or savior of versioni

["Stephen Green" <stephengreenubl@gmail.com>]

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@gmail.com> wrote:
> On 20/10/2007, Thomas Lord <lord@emf.net> 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