[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl] IND7 UBLVersionID
To clarify my argument here: Suppose the target namespace of the schema was incorrect and did not follow the UBL NDR defined rules for how a target namespace must be defined. The schema will thus never work. I suppose that we would all feel this was a non-meaningful change and change it immediately. Despite the fact that from a validation standpoint this would be a very significant change indeed. This is because we know what the namespace is supposed to be exactly due to the NDR and any variation from that is not meaningful, is the equivalent of a spelling error. In the case of UBLVersionID the change proposed is, from a validation standpoint, much less important than a namespace change and in this case we know what the cardinality is supposed to be exactly due to the NDR and I would argue that any variation from that is not meaningful, is in fact the equivalent of a spelling error. I realize that this sounds counterintuitive but I hope that consideration of the argument will lead to agreement. Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Bryan Rasmussen [mailto:BRS@itst.dk] Sendt: 31. juli 2006 09:42 Til: jon.bosak@sun.com; tmcgrath@portcomm.com.au Cc: ubl@lists.oasis-open.org Emne: SV: [ubl] IND7 UBLVersionID Hi, The documentation I was thinking of was specifically the NDR, to quote from NDR http://www.oasis-open.org/committees/download.php/19218/NDR-2006-07-19.pdf : "UBL version information will also be captured in instances of UBL document schemas 1189 via a ubl:UBLVersion element. 1190 [VER15] Every UBL document schema MUST include a required element named 1191 "UBLVersionID" as the first child of its root element. This element MUST 1192 have a default value that matches the value of the xsd:version attribute of 1193 its containing schema.Every UBL document schema MUST include a required 1194 element named "UBLVersion" as the first child of its root element. This 1195 element MUST have a default value that matches the value of the 1196 xsd:version attribute of its containing schema." I'm supposing that the NDR is not considered to be Informative, but is at a higher level than schemas. Otherwise why have an NDR for schemas (is it because one can then read the NDR to understand how Schemas are structured? but I think the NDR could be quite a bit shorter then. ) It is of course true that we will do things to bring both into agreement with each other, but I wasn't thinking Schemas overrode the NDR but rather the opposite. Anyway, it is for this reason I think we should be able to argue it is a minor change. By the way, I noticed that changes to the NDR were carried with in this version. Is that the way it is supposed to be or has the metadata not been rinsed from the document, or perhaps changes were carried with in converting from another format? -----Oprindelig meddelelse----- Fra: jon.bosak@sun.com [mailto:jon.bosak@sun.com] Sendt: 30. juli 2006 16:07 Til: tmcgrath@portcomm.com.au; Bryan Rasmussen Emne: Re: [ubl] IND7 UBLVersionID (off the list) [tim:] | what we now need to decide is whether the changing of UBLVersionID | to minOccurs=1 constitutes a significant change. If so then we | may have to let this pass for UBL 2.0 (and make a note in the NDRs | to this effect) and fix it for 2.1. I'm not sure we can let this go. It was essential to the concept of UBLVersionID that it be required. And the change would be substantive because it would affect software. I'd be glad to be convinced otherwise. | I would suppose that it is not a significant change because it is | a change to bring the schemas in line with documentation that can | be considered to be at a higher level. But we've taken the position that the documentation is informative and that we can make any changes we like to bring it into alignment with the schemas. We can't now take the position that the documentation is normative and can drive the schemas. There were other reasons to suspect that we might need one more revision cycle; maybe we'd better start planning for it. Jon --------------------------------------------------------------------- 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]