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

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

I think I agree with Fraser in that I think the stripping of non-compatible
content will have to be accompanied by better ways of defining 'profiles'.
I say this on the basis of a gut-feeling that if folk are already relying on
transformations to cater for minor version changes then it won't take
much to reuse tools for that to better cater for profiling requirements and
'customization' . If you were, say, using a subset profile which said that
the applications MUST 'understand' certain core particles both when sending
and when receiving then the extensions in a minor version might actually
be academic as the apps might prune things down more than that anyway
and therefore (provided extensions MUST be optional) be immune to minor
version extensions. The get back to the use of 'any' - that means it might be
that such extension points are pruned out in subset profiling anyway and left
to the high-end-to-high-end scenarios alone.

On 22/10/2007, Fraser Goffin <goffinf@googlemail.com> wrote:
> I think UBL proposal to have a step to strip non-compatible content is
> required only for the forwards-compatibility case for a minor version
> release of the vocabulary.
>
> What others also appear to be ignoring is that the basis of providing both
> EXTENSIBILITY to a vocabulary and along with support for minor release
> VERSIONING, are the underpinning priciples of 'must ignore' and 'must
> understand'.
>
> There is no 'magic bullet' here, the sender and receiver are passing
> 'signals' which may have associated processing requirements such as, '.. if
> you receive data in 'this' location ('this', meaning agreed extensibility
> location(s) in the vocabulary) which is signalled as FOR your attention ...
> do what is agreed'. This often forms the foundation of a private trading
> agreement that is operating within the constraint of an existing public
> standard.
>
> Similarly, '... if you see stuff in here (here, meaning agreed extensibility
> locations in the vocabulary) that you DONT understand, feel free to ignore
> it, strip it, whatever'.
>
> This approach is not without some issues, but it is a valid approach that
> operates well in some circumstances.
>
> In the UK there is an insurance standard vocabulary which most of the major
> insurance companies and their principle trading partners (brokers) subscribe
> to in terms of common definitions of a specific set of transactions. Just
> like any other, this is a competitive market-place and of course, the
> particiapnts aren't going to base their entire business operating model on
> the ability of a data standard to keep up with their specific needs in some
> (important) cases. Extensibility within the standard can play a critical
> role to both providing benefits for the community as a whole as well as
> allowing private trading relationships to flourish within the spirit of
> standard practice.
>
> Fraser.
>
>
> On 20/10/2007, Stephen Green <stephengreenubl@gmail.com> wrote:
> >
> > 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
> >
> >
> _______________________________________________________________________
> >
> > XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> > to support XML implementation and development. To minimize
> > spam in the archives, you must subscribe before posting.
> >
> > [Un]Subscribe/change address:
> http://www.oasis-open.org/mlmanage/
> > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> > subscribe: xml-dev-subscribe@lists.xml.org
> > List archive: http://lists.xml.org/archives/xml-dev/
> > List Guidelines:
> http://www.oasis-open.org/maillists/guidelines.php
> >
> >
>
>


-- 
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