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: [ver] final document


Please find attached (or below) the final output note from the VER8 / VER9
versioning team
Report from the VER8/VER9 Taskteam
___________________________________

This note is a summary of the meetings of the VER8/VER9 Taskteam (Arofan Gregory, 
Stephen Green, Tony Coates, David Kruppke)

Two alternatives were discussed:

(1) Full re-declaration of constructs in new minor versions

(2) Controlled use of substitution groups to enable the use of extension/refinement 
approach advocated in current NDR

Additionally, the use of an XML expression of the BIEs and their relationships, made 
available to processors at run-time, was discussed. While seen as potentially quite 
useful, this alternative was seen as requiring too much work for immediate use, and 
was not considered as a practical immediate option.

Further, it would not form an alternative to either (1) or (2) above, but would be a 
useful approach in combination with one or both of them. It would make a natural 
companion to approach (1), since the BIE-XML could provide inheritance relationship 
rather than expressing it in the schemas. It was generally agreed that if this path is 
taken in future, it should not be an integral part of UBL, but rather a sister-standard, 
as any CCTS-based vocabulary might find it to be very useful.

Option (1) was seen to have some advantages:

- It is more like ATG's NDR
- Use of namespace prefixes in instances is simpler

This approach has been prototyped, and is seen as the default position. It represents 
a departure from the design intended in the current NDR, but major changes to the 
NDR document itself are not required such as 
#1.1 - remove VER8 and VER9
#1.2 - add a rule (a new VER8, say) that a minor version must be such that any 
            instance valid by the previous version must require only changes to the 
            namespaces and schemaLocation attribute value in order to be valid by the 
            current version
#1.3 - change ELD2
	from: All element declarations MUST be global with the exception of ID and
        	           Code which MUST be local.
	to:     All element declarations MUST be global.
#1.4 - amend much of the prose of the NDR and possibly some of that of the 
            Customisation Methodology Paper



Option (2) was discussed as being closer to the design intended in the current NDR, 
by using extension/refinement as an explicit mechanism in the schemas. In order to 
make this approach work, a controlled use of substitutuion groups was proposed. 
Alternative approaches involving the use of extension/refinement would have some 
very negative side-effects such as impacting the namespace packaging of the UBL 
library.

In using substitution groups, emphasis is placed on the fact that their use is *controlled*. 
The NDR would explicitly state how they are to be used, according to the prototype and 
samples and the following. They would only be employed to allow the creation of 
elements reflecting extended and/or refined BIEs per the current NDRs versioning 
rules. The use of empty, abstract types permitting uncontrolled substitution of any type 
of structure whatsoever would not be contemplated, although they do facilitate 
custoimization per the existing NDR and customization mechanisms (those involving 
extension/refinement).

Note that when a substitution group is headed based on an element of a named type, 
only elements based on types which are extensions and refinements of the 
head-element's type are permitted as substitutions in XSD. Thus, the best control of the 
possible substitutions is the type of the head element. If these are normal BIEs, then 
constraints are placed on the allowable substitutions through the extension/refinement 
mechanism of XSD, in keeping with the intention of the current NDR.

Stephen and Arofan each made prototypes of this approach. Stephen's permits the use 
of both extension and refinement on a single BIE in a minor version (Types with suffix 
'...Type' could be used for restrictions which can then be extended as well using further 
types with the suffix '...BaseType' or vice versa). Arofan's allows only one or the other. 
In either case, changes to the existing NDR are not huge: 
Each element in a namespace would be declared in the new namespace as an 
extension/refinement (frequently trivial) of its corresponding type in the preceding minor 
version namespace, which would be imported. They would have the same names. A 
global element would also be declared, as normal, but it would have a substitutionGroup 
attribute pointing to its corresponding preceding minor-version namespace element. (An 
extra type declaration with "base" added to the name could be declared, also, to allow for 
both extension and refinement to a single type if desired, as per Stephen's prototype.)

References:
Stephen's prototype - 
         http://lists.oasis-open.org/archives/ubl/200504/bin00006.bin 
           (save file locally, changing extension to .zip)
Arofan's prototype (illustrative and not intended as fully conformant UBL Schemas) - 
         http://lists.oasis-open.org/archives/ubl/200504/zip00000.zip

The other necessary change is that no local element declarations are any longer 
permitted - both IDs and codelists would need to become global. 

It was noted that this approach, while in keeping with the design intent of the current 
NDR, would be very divergent from the ATG NDR. This leads to a discussion of having 
two sets of schemas, one designed according to each NDR, which would validate the 
same instances, albeit with a little bit of namespace "munging". The two sets of schemas 
would be derived from the same set of BIEs, and would in many ways have coordinated 
NDRs (namespace packaging would be 1:1, etc.) It would be possible to take the more 
metadata-rich set of schemas (UBL NDR, with extension/derivation) and derive the other 
set automatically, using XSLT or some other transformation.

This approach would have several benefits:

(1) Technologies such as XQuery which (we think - this was not fully explored) do not 
like the substitution group approach would have a useful set of schemas, as would any 
user or application which preferred the directness of the full re-declaration approach.

(2) Type-aware technologies (XPath 2.0, etc) would have a set of schemas with the 
needed inheritance information made explicit in them. (UBL NDR using approach (2))

(3) Many difficult design choices involved in merging ATG and UBL NDRs would be 
avoided through the creation of rules regarding how the namespaces generated by the 
two NDRs would be named and corrresponded (it would be best of these were 
predictable).


Recommendations:

The final recommendation of the taskteam is as follows:

(1) Make the next revision of the schemas a major release, version 2.0. This would 
allow for some of the needed changes to support this approach (global IDs and 
codelists) to be made, which in any case must be made to support the customization 
guidelines. (This would require a change to ND Rule 'ELD2', as in #1.3 above)

(2) The next version could then be a minor version using approach (2), as outlined 
above. This would buy UBL the time to fully validate this approach. (This would require 
a change to ND Rule GXS5 which currently states: "The xsd:substitutionGroup feature 
MUST NOT be used". The change to this rule might include a mention that the use for 
minor versions could also be used for customisations in accordance with the UBL 
Customisation Methodology)

(3) As possible, a coordinated release between UBL and ATG would realize the 
two-schema approach after this has been fully explored and validated.

The approach recommended seems to be - if workable - the best way both to preserve 
the existing NDR design, and to maximize benefit for the user, by providing a choice of 
schemas with differing metadata in them. Further, it may help with political challenges.





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