OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl] Minutes of Atlantic UBL TC call 2 November 2005


 
I'll work on this, and see what I can come up with.

-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Friday, 04 November 2005 1013
To: ubl@lists.oasis-open.org
Subject: RE: [ubl] Minutes of Atlantic UBL TC call 2 November 2005

To clarify:
As far as I can tell (happy to be corrected) any additions will always be within an existing complexType, so there needs to be a way to declare the resulting new complexType alongside the old one or in place of the old one. That alone creates issues (redefine and/or complexType name changes). But then the big issue, I think, is how the new complexType (with the addition) can itself get referenced (included / contained) in complexTypes which previously referenced (included / contained) the old one.

Steve
 

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 04/11/05 
>>> 14:55:41 >>>
Mike

This requires the use of redefine - which I think I've shown won't work with our degree of nesting.

Steve

>>> Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> 04/11/05 
>>> 14:46:03 >>>

> I don't see how, with UBL's highly nested schemas, you can do a delta without use of derivation and substitution groups; and to do this you have to import a previous schema/set of schemas which must therefore have a different namespace.

If the minor version schema will be in the same namespace as the major version schema, you can *include* the major version. I believe this may alleviate the need for substitution groups.


-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk]
Sent: Friday, 04 November 2005 0923
To: ubl@lists.oasis-open.org
Subject: RE: [ubl] Minutes of Atlantic UBL TC call 2 November 2005

Mmm.. namespaces including or not including the minor version number didn't figure as part of the study - it was a given, at the time, that the namespaces would include a minor version number. (That could be the subject of further study, but see below.)

*******************************************
This raises a further important point - it seems to me that the decisions for questions 1 (for minor versions just do a delta) and 2 (not include the minor version number in the namespace) are also contradictory.
*******************************************

I don't see how, with UBL's highly nested schemas, you can do a delta without use of derivation and substitution groups; and to do this you have to import a previous schema/set of schemas which must therefore have a different namespace.

To me what we had with the 1.0 NDR came as a package, apart from the need to allow substitution groups (as I think I previously proved). I don't see how you can change any of it, other than as recommended by the work team to allow the substitution groups, without it breaking. If the TC is asking for deltas in minor version schemas then we need minor version numbers in namespaces and substitution groups. If substitution groups and namespaces with minor version numbers are not to used (or just one or the other of these) then I don't see how we can have the deltas - unless someone can demonstrate this adequately to the SSC.

All the best

Steve



>>> Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> 04/11/05
>>> 13:51:57 >>>
Steve,

Was this with the assumption that the namespace would change? If everything is still in the namespace, is this still true?
 
Thanks,
Mike


-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Friday, 04 November 2005 0651
To: stephen_green@bristol-city.gov.uk; ubl@lists.oasis-open.org 
Subject: Re: [ubl] Minutes of Atlantic UBL TC call 2 November 2005

Sorry, I quoted the wrong question for one of these, I meant Questions 1 and 4 rather than questions 3 and 4

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 04/11/05
>>> 11:45:46 >>>
Please forgive my possible niaivety: I think these two decisions are contradictory (I'll be pleasantly surprised if someone proves me wrong).

I thought with the versioning team we had proved that you cannot publish deltas for highly nested schemas like UBL without using substitution groups.

All the best

Steve


The minutes read:

Question 3: What, specifically, determines whether a new version of the schema is actually a 'minor' or 'major' release? (If the schema only includes the deltas, and utilizes xsd:derivation concepts, the answer should be simpler than if the versioning is strictly model-based.)

   Discussion: We have already adopted the definitions given by
   Eduardo Gutentag in his message of 18 October 2005, but we note
   that his definition of backward compatibility transposes X and
   Y:

      c) backwards compatibility -- a schema X is said to be
      backwards compatible with a schema Y if documents that
      validate against schema X also validate against schema Y,
      and schema X follows (in time, or in version) schema Y.

      In other words, if all documents that validate against
      MySchema v1.0 also validate against MySchema v1.1, then
      MySchema v1.1 is said to be backwards compatible; but there
      is no expectation that any document that validates against
      MySchema v1.1 must also by necessity validate against
      MySchema v1.0

   The example shows that the definition should read "and schema Y
   follows (in time, or in version) schema X."

Question 4: Is (are?) Substitution Groups still on the table?

   AGREED: We will not use substitution groups for minor
   versioning.




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]