RE: [ubl-dev] Customising and versioning

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

Hi David

Good point. I just have a feeling there going to be so many
out there yet who would understand a CAM template but
would be able to sing happily to the tune of a set of schema
files. Then there is always scope to use the CAM for some
of the production systems once they have been specified
and the standards and customisations adopted.

All the best

Steve


>>> "David RR Webber (XML)" <david@drrw.info> 07/09/06 13:40:30 >>>
At the risk of sounding like a broken record - if you want to wean off
your dependency on "big oil" - aka XSD from the W3C - and use a toolset
that allows you to do minor and major versioning and extensions with
explicit referencing back to the original core components and NDR -
then CAM templates are available! 
  
DW
 


 -------- Original Message --------
Subject: RE: [ubl-dev] Customising and versioning
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Date: Thu, September 07, 2006 8:24 am
To: <ubl-dev@lists.oasis-open.org>

Excellent points, Mark. Thanks. I'll think about
and try out a few things they bring to mind.

Two of your points I'd highlight and ponder for now:
Firstly, the conformance to underlying core components.
I admit this is the first time I've personally got as far as
considering this (too tied up in the XSD before).
Secondly, the matter of customizing: I hadn't really been
dwelling on that yet so much as on internal 'customization'
as a means to produce minor versions (more the could it
be done than the should it be done).

So those two things considered at this stage (I hope to
quickly get on to wider customization though), I guess
the first thing I'd like to dwell on is how to produce a
minor version of UBL 1.0, 2prd1 or 2prd2/3 (not that
UBL 1.0 is up for minor versioning but just in theory).
The first thing after the W3C XML Schema mechanisms
to be used is the matter of the core components. I
guess it might be that either
1. there are new core components to be added (as BIEs) by
extension
2. better conformance of BIEs to existing core components
can be achieved by a mix of extension and restriction of
the existing BIEs (or just extension or just restriction).

I'll hopefully be able to go away and look at these
before moving on to wider customization mechanisms.
That's because I think the way wider customizations
are planned and implemented partly depends on what
mechanisms are available for minor versions. 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). 

Many thanks

Steve


>>> "Crawford, Mark" <mark.crawford@sap.com> 07/09/06 13:01:14 >>>
> The result, as far as I could work things out,
> was that UBL 1.0 allows derivation with substitution
> groups (despite that being at odds a bit with UBL NDR 1.0)
> as does UBL 2 prd 1, whereas UBL 2 prd 2 requires use
> of redefine (which I did manage to get to work nicely).

Stephen,

Remember, the NDR are normative for UBL schema, not customizers.  Very
early on we had this discussion on what is considered conformant
derivations and what is not.  Substitution groups and redefine are
perfectly acceptable provided you are not trying to claim conformance
since they break relationships with the underlying core components.

Kind Regards,

Mark

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