[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Rosetta Net Comments to NDR Rules
I was asked to summarise my comments from today's meeting on RosettaNet's comments. Here they are, although they have changed a little, since I had some time since to think a bit more about it. ==== Section 2.2.2: Versioning. 1. targetNamespace MUST NOT include minor version number. As [UBLN] major and minor version numbers are embedded in a particular namespace that implies that changing minor version number doesn?t allow replacement of old schema with the new schema respective to keeping the same instance documents. Suggestions: Enforce embedding only major version number in the ?targetNamespace?. This enables RosettaNet to not enforce a schema version bumping rule: A major version change happens only if an XML instance that was validated with a previous version of the schema cannot be validated with the new version of the schema. By using only the major version in namespace, needless changes to multiple files can be avoided. ==== The idea behind this RosettaNet rule is that minor version changes are backwards compatible, in the sense that any XML documents that are valid with respect with respect to a previous minor version (same major version) of the Schema are also valid with respect to all later minor versions (same major version) of the Schema. So if a document is valid under version 2.1 of the Schema, it will be valid under versions 2.2, 2.3, etc. This places restrictions on the kind of changes that can occur between two minor versions. This is a common design aspiration, that minor version upgrades are backwards compatible in this sense. The biggest problem is that there is no way to guarantee backwards compatibility computationally. There are certainly design rules you can follow which *should* lead to backwards compatible Schemas, but there is no way to be certain. That said, the risks are small. You just have to know what you will do if you do ultimately find a document that breaks the backwards compatibility rule. More of a problem is that, with no minor version information in the namespace URL, systems cannot tell if a document is intended for version 2.2. or 2.3 of the Schema. It can only tell that the document is for version 2.x of the Schema. Applications are almost never upgraded the same day that new Schema versions are released, and so it becomes difficult to protect applications coded to version 2.2 of the Schema from receiving version 2.3 documents which might cause an application failure. ==== 4. Exposing ?Schema Version? via instance documents Sometimes it is beneficial to be able to correlate a given instance document fragment to the type definition in a particular namespace so that processing application at the destination can take appropriate action(s). Suggestions: A common global attribute ?schemaVersion? of the ?xsd:token? type MUST be declared as an optional attribute for all Root Schema type definitions. Instance documents SHOULD set the value of the ?schemaVersion? attribute. The ?schemaVersion? attribute MAY contain more then one value of the Schema versions that the instance document is compatible with. ==== RosettaNet's solution to the aforementioned problem of not knowing the minor version of the Schema that a document is valid for is as above. They intend to put that information in the instance documents themselves. This allows applications to reject documents for newer minor versions that the applications are not able to handle. However, means the document must be at least partially parsed to get the version information. After that, the parsing may need to be restarted. This can be done, but the biggest problem is that few XML-aware applications make allowances for such pre-parsing, so it is difficult to get broad support for this kind of approach (which has been suggested by numerous groups in the past). RosettaNet's goals can be achieved using UBL's namespace URIs with both major and minor versioning. Standard catalogue files can be used to map all minor versions namespace URIs onto the latest minor version of the Schema. The advantage of this approach is that it works out of the box with standard XML parsers, like Xerces, and does not require the custom pre-parsing that the RosettaNet approach requires. Cheers, Tony. ==== Anthony B. Coates London Market Systems Limited 33 Throgmorton Street, London, EC2N 2BR http://www.londonmarketsystems.com/ mailto:abcoates@londonmarketsystems.com Mobile/Cell: +44 (79) 0543 9026 [MDDL Editor (Market Data Definition Language), http://www.mddl.org/] [FpML Arch WG Member (Financial Products Markup Language), http://www.fpml.org/] ----------------------------------------------------------------------- This Email may contain confidential information and/or copyright material and is intended for the use of the addressee only. Any unauthorised use may be unlawful. If you receive this Email by mistake please advise the sender immediately by using the reply facility in your e-mail software. Email is not a secure method of communication and London Market Systems Limited cannot accept responsibility for the accuracy or completeness of this message or any attachment(s). Please examine this email for virus infection, for which London Market Systems Limited accepts no responsibility. If verification of this email is sought then please request a hard copy. Unless otherwise stated any views or opinions presented are solely those of the author and do not represent those of London Market Systems Limited.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]