[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Filenames (was [ubl] Minor Versioning Example)
Noting that we have a possible further step towards better backwards compatibility in minor versions with the removal of the minor version from the namespace, would it not be an improvement yet again to remove the minor version number from the schema filenames (the filepath could be more flexibly used to distinguish versions of schemas where necessary such as for includes). I think this would allow greater flexibility when validating instances - they could be validated against an earlier schema set by replacing the absolute path with a relative one, etc. >>> "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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]