Re: [ubl-dev] Customising and versioning

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

I managed yesterday to get a full working set of 

1. UBL 2 schemas (those produced for UBL 2 public review 2)
2. derived (with redefine and susbtitution groups here and there) minor version schemas
3. customisation of the above with substitution groups

It didn't prove possible (as far as I could manage) to totally avoid minor version
namespace changes. It was OK keeping the same namespaces for types
(xsd:complexTypes) but not for elements. Elements based on those types
had to have minor-version-specific namespaces different from the types'
unchanging namespaces so they could be susbtituted using the W3C XML Schema
substution group mechanism in external customizations. The types didn't need
new namespaces as xsd:redefine can extend them without a change of namespace
so they just needed the ajor version identifier in their namespace. To give the
elements a different namespace I placed them in a separate schema file with
a target namespace which included the minor version identifier (though any difference
in the namespace would have presumably sufficed). This added possibilities for
confusion to the schema set of files though - possibly confusing for customizers.
Maybe a set of fully redeclared schema files for each minor version is more
likely to be the way UBL progresses. I think I proved the W3C XML Schema derivation
mechanism with redefine, etc and same namespace types at least is possible though
and can be a basis for derived customisations. And it was fun to do (though frequently
frustrating with limited understanding of XSD derivation largely due to relatively sparse
info in specs on xsd:redefine). It mostly all seems clear now though. Tool support was
not quite satisfactory as far as GUI was concerned and could improve some.

The whole thing would be easier using just substitution groups but that would have
required including the minor version identifiers in the namespaces so the namespace
changed with every minor version. This might not be so nice for instances though
and breaks the present UBL 2 NDR a bit. It is much more straightforward though,
especially for customisers working from such minor version schema files as their
starting point.  

All the best

Stephen Green
 

>>> "Fraser Goffin" <goffinf@googlemail.com> 12/09/06 12:07:10 >>>
> 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 
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org 
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org