I have 2 separate XSDs with some common attributes.
I want to create another XSD and put all my common attributes in the separate XSD and import them in the 2 XSDs i have already rather than repeating them or duplicating them in both the XSDs.
Is there any reference for such implementation?
Please let me know if any example or link is there..
Thanks
Related
I have a small library (JAR) containing some custom JSF-components. Some of them are composite-components which are completely (or partly) implemented in XHTML files which reside under META-INF/resources/my-components. To use these components from other XHTML-files I have to use the XML-namespace http://xmlns.jcp.org/jsf/composite/my-components.
Other related components in this library are implemented as POJOs using #FacesComponent (and #FacesRenderer). To use these components, I have to use the XML-namespace which is defined at the component's #FacesComponent-annotation (attribute namespace). At this point I can choose whatever I want (like http://my-company.com/my-components).
Since I have not found any possibility to change the namespace-prefix of my composite components, and I do not want to set my POJO's namespace to something like jcp.org (I'm not sure if this is even possible), I have to use two different namespaces to use my components coming from the same library.
But since the namespaces are different only because of an implementation-detail and maybe one component will be realized in a different way in the future, this is not what I want.
So the question is: is there a way to specify the full namespace for my composite-components? Of course, I want to use the same ones which are used for my other components (http://my-company.com/my-components in the example).
Just specify the composite library name in your *.taglib.xml file, below the namespace declaration.
<namespace>http://my-company.com/my-components</namespace>
<composite-library-name>my-components</composite-library-name>
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).
Is there a quick way to find out all the mandatory field in a xsd file?
I need to quickly see all the mandatory fields in the schema
thanks
Not sure if you're looking to do this through code. If not, Altova XMLSpy, for example, provides an option to "Generate Sample XML File" - with options to generate only mandatory fields.
Otherwise, if you're working with Java, for example, you can use something like the Eclipse XSD project for programmatic access to the XSD. (It even works without Eclipse.) Some additional details at Are there any other frameworks that parse XSD other than XSOM? .
Take a look at this post; instead of exporting all fields, there's also an option to get only the mandatory ones... One significant difference compared with the answer you accepted is in that you can also generate an Excel or CSV file, in addition to the XML file; not to mention that the sample XML approach is deficient by definition... I would pay attention to the way mandatory choices, abstract typed elements or abstract elements with substitution groups play in your case.
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.
SubSonic newbe question;
I want to put custom attributes on properties in the generated classes, is that possible?
It's definitely possible. Is this SubSonic 2 or 3? It's doable for either one, but the question of where to find the templates is different depending on which one you're using.
Edit: For SubSonic 2, follow this link and look at the entry on "templateDirectory". For SubSonic 3, you probably have some .tt files in your VS Project you can mess with.
There's two ways to do this:
If you want to add them at generation time you can do what Skinniest Man suggests and modify the templates to add them.
If you want to add them manually things are a little more tricky and you'll need to create a 'buddy class' and apply your custom attributes to that. You can see an example for data annotations here which should illustrate the concept.