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] Can Minor Versions be a base for customisation? (was M inorVersioning Example)


I do remember that the area where there was most danger of circular 
references was with datatypes that themselves had codelists.
I don't see much danger of circular includes in BIE schemas - adequately away
from datatype level. I think this may be be why the rule allows includes in
document schemas - as far from the datatypes as possible. But I think we
could have includes in any BIE schema without much danger - just not in
datatype or codelist schemas. We'd have to change either the include rule or
the substitution group rule if we are to get delta minor versions. Non-deltas
without derivation would be, I think, the only way to keep the existing rules
(though even this might break one or two e.g. VER rules). That would help
customisers and prevent some foreseen problems with minor versions
deriving from minor versions which themselves derive from previous versions.

But I think the eminent goals of:

1. customisable schemas
2. full backwards compatibility

are the two which are most incompatible and require either dropping one or compromising.

The goal

3. delta minor versions

exacerbates this since a good compromise might have been non-derived minor versions
but without namespace changes (compromises 2 a little perhaps but not 1)


>>> Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> 08/11/05 14:37:02 >>>


I agree. We certainly have to make sure that none of our decisions hinder customization. We have never really investigated all the pros/cons of 'xsd:redefine' before (as it applies to minor versions) because we were not able to use it before the decision was made to leave the namespace name unchanged.


I've also uncovered another rule that will need to be changed:

=====================================================
The xsd:include feature provides a mechanism for bringing in schemas that reside in the same namespace. UBL employs multiple schema modules within a namespace. To avoid circular references, this feature will not be used except by the document schema.

[GXS10]	The xsd:include feature MUST only be used within a document schema.
=====================================================

First of all, is this an artifact of an earlier time; i.e."UBL employs multiple schema modules within a namespace" does not seem to be true anymore? If we extend this rule to cover minor versions, are we in danger of circular references? I don't think so, but another opinion or two would be welcome.

Take Care,
Mike


-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Tuesday, 08 November 2005 0504
To: ubl@lists.oasis-open.org 
Subject: [ubl] Can Minor Versions be a base for customisation? (was Minor Versioning Example)

I'm a little concerned that we should establish as soon as possible whether, having used redefine to create a minor version, derivation can still be used for customising based on minor versions or whether customisation would become limited to that which is based on major versions only. I think it would be a problem if a series of minor versions over several years cannot readily be customised.

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 07/11/05 
>>> 19:00:00 >>>
I tried this out this afternoon (nothing better to do :-) and I did get a problem when I came to try to customise a minor version (based on 2.0 draft 2). I'm not sure what the problem is - but I'll send the files in case someone can find it out. The problem is with file /my-xsdrt/maindoc/My-UBL-Order-2.1.xsd in the package attached, where I try to use a substitution group with a schema already derived by redefine.

I had to use the 2.0 schema draft set (from August) since I foresaw problems deriving with imports when there were some locally declared elements (IDs and Codes) in 1.0

A point to note -
we need, I guess, to change namespaces to "...-2" from "...-2.0"
and this applies to the CCP hand crafted schema too

All the best

Steve



>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 07/11/05 
>>> 14:29:22 >>>
OK. Mike's example resolved my earlier concerns. 

Might I mention a new one. Eduardo and Arofan's paper http://www.idealliance.org/papers/dx_xmle03/papers/03-04-03/03-04-03.pdf 
in section 4.1.3 mentions this. 
If the namespace is the same for minor versions could that hinder customisations? A customisation has to be bound, obviously, to a particular minor or major version and must be immune from any affect of further minor versioning.

(This requires some assumptions about how customisation might be done/recommended but the most obvious mechanism is import/substitution groups while the Swedish invoice customisation does demonstrate an alternative, I think.)

Of course it could be a rule that one only customises from major versions. But what are the implications that a minor version would introduce another schema model with the same namespace? Does this make it important to keep the names of schema files from changing when importing for a customisation?

This still doesn't change my agreement that we should use redefine for minor versions, it's just something I think we should think through (even in advance of the customisation discussions).

All the best

Steve

>>> Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> 04/11/05 
>>> 18:43:07 >>>

The schemas validate at the NIST XML Schema and Instance Validation Web Services site (http://syseng.nist.gov/b2bTestbed/projects/xmlvalidation/schema_validation.html) which utilizes the  Xerces, Jing  and MSV parsers.


The instances also validate in Arbortext Epic Editor 5.1. Although this will not be a tool used by UBL implementers, I have found in the past that it is a good barometer of what is supported by mainstream XML applications.


-----Original Message-----
From: Grimley Michael J NPRI
Sent: Friday, 04 November 2005 1213
To: ubl@lists.oasis-open.org 
Subject: RE: [ubl] Minor Versioning Example (was [ubl] Minutes of Atlantic UBL TC c all2 November 2005)


> How do other tools and validators cope with it?
> Does it have the same tool support to visualise an 'audit trail' (such as to show where a complexType is derived from another with a name change)?

I will try it out with other tools as soon as I can (which may not be for a while).
Hopefully some of our other members can give it a try...


> Does it force the use of the same namespace for minor versions?

Yes; that is why it can't be used by customizers.

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