I Googled this Question but still i'm unable to find the best difference for the Simple XSD (XML Schema Definition) Element and Complex XSD Element.
Any guidance would be highly appreciated.
I have no idea, why I answer this. But...
To summarize,
simple types can only have content directly contained between the element’s opening and closing tags. They cannot have attributes or child elements.
complex types can have attributes, can contain other elements, can contain a mixture of elements and text, etc etc.
One is a single value and the other a compound value.
Related
With ValueTuple in C# 7, it is now possible to write methods and properties that return or consume composite objects without explicitly declaring a type. These named tuples can however be potentially confusing when no documentation is provided.
As the primary and probably most convenient way of documenting libraries is by using XML documentation, is there any way using XML documentation to provide a description of the variables in a named tuple?
I know the obvious solution is to declare a type and document it accordingly. However, granted that due to some 'reasons' that cannot be done, is it possible to XML document the data members in a ValueTuple?
NB: A similar question was asked before the advent of the ValueTuple.
C# has no special syntax for documenting named elements of a tuple, you will have to use the normal <returns> and <param> elements and explain in words what each named element contains.
Though there is a proposal for adding this capability to the language.
I have a preexisting XML document type that has an element that can have two content types: some elements, or just text. Modeling this as mixed content is overkill, and JAXB's XJC creates a very ugly binding as a result.
<bars><bar .../><bar .../></bars>
versus
<bars>Just a bunch of #PCDATA</bars>
xs:choice seems structured only for complex types (not simple types like xs:string). Is there a way to express this choice, between elements or text, using XML schema? In DTD this would be something like
<!ELEMENT bars (#PCDATA | bar*)>
The language you want to define (either a sequence of character or a sequence of bar elements, but not a mixture) cannot be defined in XSD 1.0 (or in XML DTDs, either; your DTD notation would make sense but is not legal in XML DTDs).
In XSD 1.1, you can use an assertion to ensure that if any bar elements are present as children, no text nodes occur (or only text nodes that contain only whitespace).
A simple way to achieve roughly the same effect is to say that the bars element contains either a sequence of bar elements or a single stringvalue element (call it whatever you like), where the stringvalue element contains -- as its name suggests -- just a string of characters.
Lets pretend I have an XSD document and I want to produce a list of all elements along with their attributes and the children of the elements. I could also approach this by asking if you are to implement code completion based on an xsd document, and you want to list the children of the element and an elements attributes, how would you approach this problem?
Since XSD is valid XML document it just a matter of selecting XML parsing library of your choice. For example XLinq (.NET FW 3+) will do the job.
You can just walk through complexType, sequence and other elements to find out a list of possible values.
I am using a xsd schema file; there I specified an ordered list.
When parsing an XML node of the kind...
<myOrderedList> "element_1" "element_2" "element_3" </myOrderedList>
(which is valid XML syntax)
...all XML parsers I know parse this as a single node element.
Is there a way to get the XML parser parse this list for me (return it as a list or an array or whatever) or do I always have to parse it myself?
Why not make use of XML's ability to structure your data, and put each element in it's own XML element ? e.g.
<myOrderedList>
<element>1</element>
<element>2</element>
<element>3</element>
</myOrderedList>
etc. Otherwise you're having to implement parsing (albeit in a simple fashion) on top of the parsing effort that the XML parser is performing for you ?
If you do the above, the parser will return you the ordered list without any further work, and/or you can process it more easily using standard XML tooling like XSLT/XQuery etc.
Values in a list type are always separated by whitespaces so you can easily pass that through a tokenizer to get the list of values.
There are technologies like XSLT 2.0 schema aware that will see the list of values for such an element.
Using elements as proposed in the other answer is also a solution and may ease your processing. In XML child nodes are ordered so you should not worry about that. A possible representation would be:
<myOrderedList>
<value>element_1</value>
<value>element_2</value>
<value>element_3</value>
</myOrderedList>
Suppose we have a stylesheet which pulls in metadata using the key() function. In other words we have instance documents like this:
<items>
<item type="some_type"/>
<item type="another_type"/>
</items>
and a table of additional data we would like to associate with items during processing:
<item-meta>
<item type="some_type" meta="foo"/>
<item type="another_type" meta="bar"/>
<item type="yet_another_type" meta="baz"/>
</item-meta>
Finally, suppose we want to do schema validation on the instance document, restricting the type attributes to the set of types which occur in item-meta. So in the schema we want to use key/keyref instead of restriction/enumeration. This is because using restriction/enumeration will require making a separate list of valid type attributes.
However, it doesn't look like key/keyref will actually work. Having tried it (with MSXML 6.0) it appears the selector of a schema key won't accept the document() function in its xpath argument, so we can't examine the item-meta data, whether it appears in an external file or in the schema file itself. It looks like the only place we can look for keys is the instance document.
So if we really don't want to have a separate list of valid types, we have to do a pre-validation transform, pulling in the item-meta stuff, then do the validation, then do our original transform. That seems overcomplicated for what ought to be a relatively straightforward use of XML schema and stylesheets.
Is there a better way?
Selectors in key/keyref allow only a very restricted xpath syntax. Short, but not completely accurate: The selector must point to a subnode of the element declared.
The full definition of the restricted syntax is -> here.
So, no I don't see a better way, sorry.
BTW: The W3C states that this restriction was made to make life easier on implementers of XML Schema processors. Keep in mind that one of the design goals of XML Schema was to make it possible to process a document in streaming mode. That explains really a lot of the sometimes seemingly random restrictions of XML Schema.
Having thought about it a little more, I came up with the idea of having the stylesheet do that part of the validation. The schema would define the item type as a plain string, and the stylesheet would emit a message and stop processing if it couldn't look up the item type in the item-meta table.
This solution fixes the original problem of having to write down the list of valid types more than once, but it introduces the problem that validation logic is now mixed in with the stylesheet logic. I don't have enough experience with XSD+XSLT to tell whether this new problem is less serious than the old one, but it seems to be more elegant than what I wrote earlier about pulling the item-meta table into each instance document in a pre-validation transform.
You wouldn't need to stop the XSLT with some error. Just let it produce something that the schema won't validate and that points to the original problem like
<error txt="Invalid-Item-Type 'invalid_type'"/>
Apart from that please keep in mind that there are no discussion threads here. The posts may go up and down, so it's better to edit your question accordingly.
Remember, the philosophy here is "One question, and the best answer wins".