Home > Net >  Does xst:type change the element processed or just the type value of the data provided?
Does xst:type change the element processed or just the type value of the data provided?

Time:01-02

Within XML there exits elements and attributes. There is a special attribute called xsi:type. Can I declare an xsi:tpye value within the same namespace as the element in which it occurs? Example using Dublin Core.

Element Example

 <dcterms:dateCopyrighted>2022</dcterms:dateCopyrighted>

Question: Is the following Valid?

 <dcterms:dateCopyrighted xsi:type:="dcterms:W3CDTF">2012-11-11</dcterms:dateCopyrighted>

Please help me better understand what is happening in the questioned code. Is the whole declaration of the dcterms:dateCopyrighted being replaced by dcterms:W3CDTF and therefore impacting the type of the element's value, so the processing follows the rules for dcterms:W3CDTF or is only the only the type value of the data being being changed (rather than the actual element)? For example, lets imagine the expected value for dcterms:dateCopyrightedis a literal, while the type of dcterms:W3CDTF is a non-literal (to be clear this is not the case with these Dublin Core elements). So, in this case would the element be replaced and then the value type changed, or would the element stay the same and simply the value's type changed?

I found the type chart here helpful. In my specific case I am dealing with two different complexTypes.

CodePudding user response:

In the absence of xsi:type, the schema processor will decide what type to validate dcterms:dateCopyrighted against by looking at the declaration of the element dcterms:dateCopyrighted in the schema. You can use xsi:type to nominate a more specific type for validation: this must be a type derived (by extension or restriction) from the type that would have been used otherwise.

In your question, I'm not sure what you mean by "a literal" and "a non-literal", but you can't use xsi:type to bypass the validation that would have happened anyway, you can only use it to define additional constraints that the data must satisfy.

  • Related