The company I am working for at the moment codify the schema or contract version into the root node. For example,
<PurchaseOrder_v1_2 xmlns="http://someNamespace">
...
</PurchaseOrder>
I am looking for people's opinions on this design approach, as I am not convinced it is sound. For example, it requires that all services using this schema as a messaging contract are able to publish multiple versions to satisfy client requirements for different versions.
I would probably disagree with #hacktick's suggestion that versioning the namespace is conventional. I've never seen the W3C recommend that the namespace changes with version - certainly W3C namespaces don't do this - both versions of XSLT have the namespace http://www.w3.org/1999/XSL/Transform, for example.
Both encoding the version into the root and the namespace are changing the name of the element. In the case of the root, you are effectively stating that is an entirely different element with no defined relationship to the PurchaseOrder element in the previous version. In the case of the namespace change you are stating the same thing about *all the elements in the language.
Version attributes are more normal. May I suggest you read this thread on the XML-dev mailing list for some very well-informed discussion?
normally you versionize the url for the schema.
so you would have a schema called "schema" and you would then make reference to this like:
"http://www.example.com/2011/01/schema" where 2011 and 01 are versions in the form of year and month.
Example:
<PurchaseOrder xmlns="http://www.example.com/2011/01/schema">
</PurchaseOrder>
another approach is to use specify the version in the root element.
if your root-element for example is called "PurchaseOrder" you would add an required version attribute (""). your version attribute would contain a simple number that increments with each version of your xsd. you must save a history of all your public xsds. this could lead to easier xsd urls but the extraction and the validation of these xml-files is a little bit harder.
Example:
<PurchaseOrder version="1" xmlns="http://www.example.com/schema">
</PurchaseOrder>
If you versionize the root element name ("PurchaseOrder_v1_2") you would have conversion problems in your xml-files if you go for another version.
Personally i would go for solution 1 (versionized namespaces). this is also recommended from the w3c. can't find a link for this statement though.
Related
Just like TImageList contains a collection of images, is there a similar component for generic files?
I know I can embed files as resources, but I'd like the convenience of storing different groups of files in different "TFileList" components, and to be able to retrieve files by name or by their position in the list.
Extra points if such a component allowed some sort of design time preview of the file content (just like TImageList lets you see what each image looks like, at design time).
(I come from Delphi where I wrote my own component to do the above, but before I rewrite and port the property editor and all that to Lazarus, maybe there is already something that is tried and tested...)
Thanks!
You can use pre-defined lazarus TFPGList to specialize list of the type, that you want, for example - UTF8String
But, there's no T<>List as a component, only as object.
So, yes, this feature will be useful and i can implement, if have time,
also, there's a very limited RTTI, which has been updated only a few months ago, so you can access Methods and Properties now, so FP is more systemized, than delphi pascal, but also not so enterprise-developed, which limits it to implementations for common opensource and shareware project problems.
Nevertheless, it is more stable and supported, even my friends can contribute.
Two questions, hopefully with similar answers.
I'll be releasing a JavaScript package in my solution where the error messages are to be displayed. The problems is that I'll be targeting German, English and French. Possibly, also a fourth language TBD. What would be the nicest way to resolve this?
The label names should definitely be localized. Is there a built-in approach to that in CRM 2011? Like a resource table or something like that?
My current solution for (1) is to keep an extra web resource with the strings and distributing a different file for each language. I may rebuild it and distribute all the languages at once and only use a parameter, possibly settable from the GUI if I create a settings-entity. A bit cumbersome.
My current solution for (2) involves a lot of praying and a divine act of some sort. :)
To determine current CRM user language dynamically from Javascript you can use window.USER_LANGUAGE_CODE (this variable exists on all CRM pages) - for example it will be equal 1033 for English. Than based on that info, you can pick needed string resources from your file.
Also in forms context there are two predefined functions, which return current Organization language code and current User language code: Xrm.Page.context.getOrgLcid() and
Xrm.Page.context.getUserLcid() .
If you are talking about custom entities and fields, you can easily add localized display names for them via your solution. You need to edit customizations.xml file from your unzipped solution. For each attribute there you will find such XML containing display names:
<displaynames>
<displayname description="Created By" languagecode="1033" />
</displaynames>
You can just add new display names for each language you need there.
P.S. If someone interested in different aspects of multilangual support for Dynamics CRM 2011 solutions, I strongly recommend to review this page, also here and here is a very helpful reading.
Seems that the /docbook-5.0/catalog.xml (XML catalog) found in the DocBook 5.0 zip ...
http://www.docbook.org/xml/5.0/docbook-5.0.zip
references a xsd/docbookxi.xsd schema file that seems to be missing from that archive.
Is this just a placeholder for some functionality that is yet to exist, or is this a legitimate error/bug/oversight in that catalog file?
Doing some google searching for docbookxi.xsd just turns up hundreds of references to this DocBook xml catalog reference, but no reference to the actual docbookxi.xsd file / definition.
Due to limitations in the environment i'm working with, I cannot use the alternative RELAX NG versions of this schema.
Yes, that's a legitimate bug. I don't actually recall if the toolchain that built the (awful) XSD versions was ever able to produce the XInclude version.
I can try to create an XInclude version of the "by hand" XSD files. However, that will be a version 1.1 XML Schema. Is that good enough, or do you need 1.0?
[Addendum]
After some investigation, it appears to me that the UPA rule in XSD makes creating an XInclude version enormously difficult. Simply allowing XInclude at either the division level (part or reference) and the component level (preface, chapter, et. al.) violates the UPA rule because a book can start with either a division or a component.
Perhaps http://docbook.org/xsd/5.0b2/docbook-xsd10.xsd or http://docbook.org/xsd/5.0b2/docbook.xsd is what you are looking for? Since the XSD schema documents for Docbook are now maintained by hand, it may well be that there are versions of the normative Relax NG schema for which no corresponding XSD schema document is provided.
I got an .xsd scheme that has multiple root elements, few complex and simple types, complex types refer to those root elements. I can't generate .xml in a way i want from it because of those root elements. So i think i need to add element that will serve as the root element, and add all other elements as its children, or am i wrong?
Is there a tool that can help me create root element and refactor scheme? What i got:
I was thinking maybe i just need to create another xsd with 1 element and ref all elements form first xsd in it, but i don't exactly know how to do it. Is this a good idea?
The answer to your edit is indeed, as Pangea said, NO. And that is because to ref another element (as in <xsd:element ref="SomeElement" ... />), the referenced element must be declared globally.
Other scenario that requires global elements is the use of substitution groups. What I am trying to suggest is that it may not always be possible to refactor an XSD in a way that leaves global only the elements you want as root in instance XML.
Which should make you think that to solve your problem, a better way might be to go after the reason why you can't generate .xml the way you want. If you can describe a bit of that, you might get a better answer here...
Another reason I wanted to add this answer was that I noticed the use of XML as a tag name. While it may seem OK, I can tell you that I've seen some pretty "big-name" applications that would simply choke with that <XML/> tag name. XML is actually "reserved", please take a look at this section of the XML Spec. To quote: "Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification."
Always play nice with the specs....
Any global element you define in the schema is a potential root element in the the instance document. If you doesn't want this behavior then make sure you have only one global element definition in the xsd. It has nothing to do with the tool (though xml editors can simplify this).
I have an XSD that's going through a transition from one set of elements to another. During the transition, there'll be code expecting the new elements and code expecting the old elements. Therefore I need to keep the old elements in the XSD; I'm documenting them as deprecated (using free text in an xs:documentation element).
Is there a way of marking an element as deprecated such that a tool like xmllint will automatically warn if someone uses a deprecated element?
Create a new schema, with a new namespace. Call this "version 2". If you choose to support version 1 XSD and version 2 XSD in your application that's fine, but keep them seperate and don't try to layer the two on top of each other - especially if you're going try to stop people from using the version 1.
This is worth looking at as it describes some of what you're dealing with:
archive of http://www.pluralsight.com/community/blogs/tewald/archive/2006/04/19/22111.aspx
I realise, however, that doesn't really address your question. With regard to "is there a way to do this?" the answer is "no - not in a universally supported manner". I've seen people add their own doc annotations to give hints, but this isn't going to be universally understood by tooling.
Your best bet in the long run is to create come up with a versioning story for your schema(s) and keep version 2 seperate from version 1.