Re: [ubl-dev] Customising and versioning

["Fraser Goffin" <goffinf@googlemail.com>]

> So just a benign version indicator on the schema root element is all
> that is needed - such as either a version attribute or changing the URI
> of the root namespace with a #1.0, #1.1, #2.0, etc.

Personally I wouldn't change a namespace for a minor revision. A
namespace change is a 'breaking' change and means that implementers
end up having to either a) upgrade their processing logic, and/or b)
support multiple concurrent versions which have much greater churn.
The version attribute idea is OK although of course it means that
processing logic has to take notice of it.

Fraser.


On 11/09/06, David RR Webber (XML) <david@drrw.info> wrote:
> Steve,
>
> Actually the opposite - it frees the schema up from attempting to
> provide atomic level of versioning details at all.
>
> So just a benign version indicator on the schema root element is all
> that is needed - such as either a version attribute or changing the URI
> of the root namespace with a #1.0, #1.1, #2.0, etc.
>
> DW
>
>
>
>  -------- Original Message --------
> Subject: RE: [ubl-dev] Customising and versioning
> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
> Date: Mon, September 11, 2006 5:10 am
> To: <ubl-dev@lists.oasis-open.org>
>
> Thanks David,
>
> Does this put any requirement on the schema design or versioning
> strategy then?
>
> Steve
>
> >>> "David RR Webber (XML)" <david@drrw.info> 08/09/06 19:58:48 >>>
> Steve,
>
> We finesse this in CAM by separating the structure handling from the
> versioning mechanisms.
>
> By using UID overlay values on top of the structure you can call-out out
> versioning details.  These can either be in-line CAM namespaced
> directives (that are therefore stripped out and invisible relative to
> the UBL content), or use the explicit UID mechanism in the data
> referencing section of the CAM template to point to XPath of item(s)
> that are versioned relative to the main content.
>
> In XSD you could attempt to do this via attributes that are optional and
> then take a default value of a versionID (so they only show up in the
> schema and DOM - but not the XML instance).  But then you have several
> issues - first you cannot version attributes, and second - the XSD
> validation itself - you cannot direct that via a context mechanism (as
> in CAM) that then changes the structure selections based on that.
>
> By having a complete separation as in CAM - it means your XML instances
> do not change appreciably from version to version - so you have easy
> backward compatibility - yet you have agility - because your templates
> carry the versioning directives - and these provide single points of
> updating and maintenance.  Added to this you want fault tolerence - so
> the validation fails gracefully - or simply ignores optional
> non-relevant content.  Whereas in the XSD paradigm - the slightest
> structure deviation causes an error and processing to stop.
>
> DW
>
>
>
> -------- Original Message --------
> Subject: RE: [ubl-dev] Customising and versioning
> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
> Date: Fri, September 08, 2006 5:08 am
> To: <ubl-dev@lists.oasis-open.org>
>
> Correction #2 (sorry folks, rushing too much)
> "You could say to me, yes but you can use substitution
> groups with a redefine (thanks again to Joe for pointing
> this out to me months back). "
> should read
> "You could say to me, yes but you can use substitution
> groups with a xsd:include (thanks again to Joe for pointing
> this out to me months back). "
>
> >>> Stephen Green 08/09/06 10:05:40 >>>
> Correction to first sentence
> "(though with a bearing on
> any subsequent minor versioning of a minor version so derived)"
> should read
> " (though with a bearing on
> any subsequent customization of a minor version so derived)"
>
>
> >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 08/09/06 10:02:39 >>>
> Hi Mark
>
> I'd stress again that I'm talking minor versioning here rather
> than customization in general (though with a bearing on
> any subsequent minor versioning of a minor version so derived).
> The problem is that the namespace is supposed to stay the same.
> This is what seems to me to hinder use of substitution groups
> for it, otherwise you get a nameclash. You can't base a
> substitution group on itself :-)
>
> You could use substitution groups fine for minor versioning
> in UBL 2 prd1 as the namespace for the minor version was
> different from the previous version so an Order say could
> use substitutionGroup="po:Order" where po is the prefix
> of an imported Order schema with the previous version
> namespace. Changing the namespace so it only has the
> major version identifier removes the possibility of import.
> You could say to me, yes but you can use substitution
> groups with a redefine (thanks again to Joe for pointing
> this out to me months back).
>
> The problem then is you can't say;
> <xsd:element name="Order" substitutionGroup="Order"/>
> because then there are two elements both called Order
> in the same namespace. Plus you can't base a substitution
> group on itself. Change the name of the element??
> Mmm... Hardly minor versioning.
>
> All the best
>
> Steve
>
> >>> "Crawford, Mark" <mark.crawford@sap.com> 07/09/06 18:09:23 >>>
> > For instance,
> > not knowing what mechanisms will be used but knowing that
> > there is a barrier to using substitution groups for it in
> > UBL 2, leads to the conclusion that one might have to think
> > how to customize a redefined schema and if this is indeed
> > a major problem, one might wish to feed this back to UBL
> > as the NDR 2.0 goes to public review (perhaps shortly
> > from the look of the recent minutes).
>
> Could you be more specific - what barriers are there to substitution
> groups in UBL2?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>