Is there a way to require an element depending on the enumeration value entered for another element?
Basically, what I'm trying to do is have an user interface type defined by an enumeration. Depending on the interface type, some fields may or may not be required.
I understand this could be achieved either by making the elements optional, and handling the conditional logic in the Code, or by making different complex types for every possible interface type. However, I want the rules to be apparent to anyone reading the schema, so the Code solution wouldn't be ideal, and adding a ton of complex types, even though they share most of their required fields in common, would add a lot more to the xml parsing logic.
Is it possible to have all this logic contained in the schema to simplify validation and parsing?
This kind of conditional mandatory/optional element inclusion is not possible with XSD.
You can do that using RelaxNG.
You will have a good technical data interface with this kind of schema (describing exactly the structure you want, with a tool like Jing for validation).
And then, if you want to use object mapping, you can use Trang to convert your RelaxNG schema to an XML Schema (the XML Schema will be little more loosy, the true data interface beeing described in RelaxNG).
Related
I'm new to Dita, so I apologize for any ignorance.
I'm using XJC to compile the base (and only the base) Dita 1.3 schema into Java classes. When I attempted to compile all the XSD files, I received errors with elements and groups being redefined. None of the XJC bindings I attempted to write would fix it.
After digging through the schema, I found that mapGrp.xsd/mapMod.xsd and topicGrp.xsd/topicMod.xsd contained the same group and element definitions. This explains why XJC would fail when including all of the XSD files. The XSD parser itself cannot handle these duplicate entries.
So I generated basemap.xsd and basetopic.xsd separately and cleaned up the generated code so I could run a diff against the two directories.
I found that the two schema's have some elements specific to maps and topics. For example, the map schema has DitavalmetaClass and DvrKeyscopePrefixClass while the topic schema doesn't. And the topic schema contains AbstractClass and BodyClass while the map schema doesn't. But the majority of classes are shared between the two schema's.
As for the classes that are shared, there are only three that have some differences between the two schema's (LinktextClass, MetadataClass, and SearchtitleClass). Even then, they aren't big changes, just some differences in what they can contain.
My question is, why couldn't the shared classes go under one common Grp/Mod schema that's shared between topic's and map's and redefine those three classes? Can I change the two schema's so they share the same elements and groups without breaking any of the other schema's that extend the base schema?
Maps and topics are two distinct document types. They share some element types in common but are otherwise completely independent document types.
Note also that DITA does not have "a single grammar" in the way that other XML applications do (or appear to do).
DITA is explicitly architected to allow controlled extension from the base grammars so that you can do any of the following:
Configure a given map or topic type to include or exclude specific elements, either other topic types (in the case of topics) or specific element "domains" (sets of "mix-in" elements). Thus there can be two different working grammars for "topic" documents that allow different sets of elements.
Add "constraint" module that restrict existing content models or attribute lists in some way (for example, disallow a base element type in a specific context).
Define your own new element types and attributes via "specialization"
Thus any attempt to generate things like Java classes or database schemas for DITA in any sort of static way are doomed to fail in the general case.
If you are implementing code that needs to operate on any conforming DITA document then it needs to be more flexible and operate on elements in terms of their #class values, not their tag names.
If it is sensible for you to generate Java classes from the XSDs you must treat each top-level map and topic type (map, bookmap, subjectScheme, learningMap, topic, concept, task, general-task, reference, glossentry, etc.) as a distinct class hierarchy--you cannot combine them in a single hierarchy because they will have different content model rules for the same element types.
You should definitely read the DITA Architecture specification:
http://docs.oasis-open.org/dita/v1.2/os/spec/architectural_specification.html#architectural_specification
Cheers,
Eliot
The DITA 1.3 XML Schemas are not manually put together anymore. They are being generated automatically from Relax NG schemas which are the officially supported schemas by the specification. Maybe you should also take a look at the DITA 1.2 XML Schemas, those were manually written and they might be better modeled to reuse more element definitions.
I have several schemas that inherit one or more elements from a collection of 'common' schemas. In this particular instance, I'm importing one of these schemas to make use of a single complex type defined in it.
When I generate the java objects from the schema, I get my schema types, and the element I referenced as expected, however I also get objects generated for the 30+ other types from the common schema.
I want to use the common schema, because I want to rely on automated builds for updating my schema when the common schema changes, but I do not want the extra java classes generated.
Suggestions ?
There's no out of the box approach to achieve what you want. The reason I am offering an opinion here is rather to point out (maybe for others) some issues one needs to take into account no matter which route ones go.
The 'extra' label is not always straightforward. Substitution group members are interesting. In Java, think about a class (A) using an interface (I), and a class (B:I) implementing (I). Some may say there's no dependency between A and B, while others would require B in the distribution. If you replace (I) with a concrete class, things become even less clear - consider that the substitution group head doesn't need to be abstract; or if the type of the substitution group head is anyType (Object in Java).
More so, if the XML processing was designed to accommodate xsi:type then it is even harder to tell (by looking at the schema) what is expected to work where.
Tools such as QTAssistant (I am associated with it) have a default setting that will pull in all strict dependencies (A and I above); and either ALL that might work (B above), or nothing else. Anything in between, the user needs to manually define what goes in the release. This is called automatic XSD refactoring and could be used easily in your scenario.
I'm developing a rather large XML Schema to integrate multiple disparate systems. Each system has messages that consist of multiple fields. I've written the schemas so that each field is represented as a type (either simple or complex), while the entire message is represented as an element with a sequence of multiple types.
When defining types using XSD, what is the convention in terms of how you break up your files?
I've been going down the path of having a separate XSD file for each type that I am defining, then a single XSD file that defines the message and imports the required XSD files.
Here's a simplified example showing the structure (can't post images, no reputation).
Type schemas (fields) have a namespace ending in "types", while message schemas have a namespace ending in "messages".
My reasoning was that it would be easier to compose new types using existing types if they were defined in their own file, and that versioning types might be easier.
Is there a better approach? I'm relatively new to XML and Schemas. Thanks in advance.
It makes no sense to have one schema per type. One schema per domain area, yes, but not one per type.
For instance, you might have one schema to define types related to customers, and another schema to define types related to products. You might have a separate schema to define common types like people and addresses, which might be used by the customer schema and also by the product schema (product sales rep, vendor address).
You might combine these in a schema related to order processing, since it involves orders made by customers for products.
Are the separate xsd files you created completely unrelated to eachother? For example if one xsd file handles the sales domain and the other one handles the payments domain, you should give each schema a unique domain specific targetNamespace. This approach is called "Heterogeneous namespace design" and you are using it now. I believe it is best suited for your requirement. Since you are having multiple disparate systems it is better to maintain them in separate xsd files with different targetNamespaces. This enhances re-usability and reduces redundancy of types/fields. It also prevents namespace collisions. However if you have a large number of imports it becomes a challenge to manage and there will be dependency on the granularity of the types defined in the imported schemas.
If they are related to each other you should go for "Homogeneous namespace design".
There are two other approaches for XML Schema design:Homogenous Namespace Design and Chameleon Namespace Design which may not best suit your specific requirement. You can further get details on the benefits/drawbacks of all these three different schema design approaches at http://technologyandleadership.com/three-schema-design-approaches/
I need to select a modeling method for documenting extensions to an existing collection of web services. The method/tool needs to be used by tech business analysts. The existing API is defined in XML Schema. XML Schema work well with the one exception. Take a PaymentInformation class as an example. One partner might accept Visa and Mastercard as an example. Another also excepts Amex. We want to be able to extend PaymentInformation for PartnerA and PartnerB.
class PaymentInformation
method // CASH,CC
ccNumber
ccType // MC,V,AMEX
class PaymentInformationPartnerA
method // CASH,CC,PAYPAL
ccNumber
ccType // MC, V
The problem with XML Schema is that to apply a restriction to a class requires redefining the whole type. This seems like a maintenance nightmare. UML doesn't seem to support restricted strings (patterns, length, etc). What tool/method do you recommend for this? We have a preference, but not a requirement for Eclipse IDE.
You can add an UML constraint or a condition on your class. This is either a graphical note or directly an information hand coded on the UML metamodel.
The UML model is already an XMI 2.1 therefore like a XML but using specific rules.
Don't do that. If PaymentInformationPartnerA extends PaymentInformation then for all uses of PaymentInformation you can use PaymentInformationPartnerA, whereas you are saying that for some uses ( assigning a value to ccType of "AMEX" ) it is not covariant.
You're probably better off putting the constraint as a pre-condition of the endpoint receiving the message rather than as a constraint on the message type itself.
Does anybody know where I can find documentation on how to write annotation schemas for Callisto? I'm looking to write something a little more complicated than I can generate from a DTD -- that only gives me the ability to tag different kinds of text mentions. I'm looking to create a schema that represents a single type of relationship between five or six different kinds of textual mentions (and some of these types of mentions have attributes that I need to assign values to), and possibly having a second type of relationship between the first two instances of the first type of relationship.
(Alternatively, does anybody know of any software that would be better for this kind of schema? I've been looking at WordFreak, but it's a little clumsy, and it doesn't support attributes on its textual mentions.)
Creating an XML DTD with one XML tag for each type of textual mention (and attributes on the tags to indicate the attributes), and using an "id" attribute on every tag that the annotator has to fill in himself (a monotonically increasing integer). Then I used the DTD schema generator to create a Callisto schema.