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


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