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 20 April 2005


Congratulations on coming to a decision!

I apologize that I have been unable to participate lately, but given the 
announced agreement to go with a number of changes, can we include an 
explicit statement regarding "active vs. passive extensibility[1]" which 
was interpreted succinctly under "Guidelines for Designing Extensible XML 
Formats[2]"?

For example, if we decide to actively support others adding to a UBL 
instance will we be adding wildcard element placeholders at the end of 
*all* content models so that users of UBL can add their own elements in the 
tree at the end of any branch of the tree and still have the instance 
validate against the published UBL XSD files?  Users can then pass their 
documents against their own schemas for validating their augmentations to 
an instance.

I apologize if this has come up already in discussion, but I haven't been 
able to be part of the discussion, and I wasn't prepared to bring it up 
until we were going to do enough of a change to warrant UBL 2.0.

And I think we should have no qualms about a total revamp for a 2.0 as the 
basis for incremental upgrades from now on because we can cite lessons 
learned and deployment experience, with which we can claim a successful 1.0 
release.

I hope this helps.

. . . . . . . . . . . . . Ken

[1] 
http://www.pacificspirit.com/Authoring/Compatibility/ProvidingCompatibleSchemaEvolution.html
[2] http://www.xml.com/pub/a/2004/07/21/design.html

At 2005-04-20 17:46 -0700, jon.bosak@sun.com wrote:
>       AGREED:
>
>        - We will call the next version UBL 2.0
>
>        - We will redeclare the whole schema set
>
>        - We will explain that we are not adopting this monolithic
>          approach as our strategy for versioning and that we
>          still intend to produce a methodology for minor versions
>
>        - We will make everything global (i.e., change ID and Code
>          to global)
>
>        - We will align with the ATG NDRs as far as possible, in
>          particular with regard to the CCTS modules
>
>        - We will continue work on a minor revision strategy,
>          recognizing that we already have a workable proposed
>          solution that we nevertheless need to discuss further
>
>       Remaining issues for next round of NDR team work in Atlantic
>       calls:
>
>        - Whether namespaces change in minor versions
>
>        - If so, how namespace prefixes are to be versioned
>
>        - Whether we need to use substitution groups to effect
>          minor versioning
>
>        - What degree of backwards incompatibility we can tolerate
>
>        - How today's decision affects NDR changes decided
>          previously
>
>        - Issues that still remain on the issues list


--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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