Declaring an attribute for a different namespace in XML Schema - xsd

I've been using an XML format that is a mix of different existing formats and some custom elements and attributes, and I thought I should write a schema for those custom bits.
One thing I do is use custom attributes on elements in existing formats, like this:
<ns1:something attA="b" attB="a" ns2:extraAtt="c"/>
I understand that doing this is allowed but I cannot think how to declare my "extraAtt" in XML Schema or, worse, in a DTD.
I have tried reading the specification, but it could just as well be written in Chinese as far as I am concerned. Most tutorials talk only about "name", "type", and "use", e.g. this one and that one.

Each schema document defines components (pieces of a schema) for one namespace. So to define your attribute ns2:extraAtt you want a schema document something like this one:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/my-ns2">
<xs:attribute name="extraAtt" type="xs:anySimpleType"/>
</xs:schema>
The declaration of element ns1:something will need to allow for this attribute somehow, either with an attribute reference (<xs:attribute ref="ns2:extraAtt"/>) or with an attribute wildcard (<xs:anyAttribute namespace="http://example.com/my-ns2"/> or similar).
Sorry about the legibility of the spec; it's a long story, but essentially some members of the WG did not think people like you exist ("no one except implementors reads the spec, and as long as they don't complain it's readable enough" -- at least, that was what they said before some implementors did complain, loudly and bitterly; then they just changed the subject).

To declare just the attribute you can use this XSD:
<xs:schema
targetNamespace="theNamespaceUri"
elementFormDefault="qualified"
attributeFormDefault="qualified"
xmlns="theNamespaceUri"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:attribute name="extraAtt" type="xs:string">
</xs:attribute>
</xs:schema>
(assuming extraAtt is a simple string - you can use any type, or restrict an existing type etc.)

Related

Extend & redefine an XSD in Enterprise Architect

I'm creating an XML schema definition that extends an existing XSD (which was generated from a model built in Enterprise Architect) - I'm not permitted to modify the text of the existing XSD for copyright reasons, but I can reference it. The core aim is to be able to create elements from the original schema but add new sub-elements to them (the new sub-elements will be defined in a new namespace).
I've done what I needed to do by hand-crafting a new XSD based on the solution from How to extend a complex type in a different namespace without changing name which uses xs:import and xs:redefine to refer to and extend the original schema - so far so good! For completeness, the solution required two XSDs to define the new elements and then redefine the old namespace.
new.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
xmlns="new-namespace"
xmlns:bs="old-namespace"
targetNamespace="new-namespace">
<xs:import namespace="old-namespace" schemaLocation="old.xsd"/>
<xs:element name="myElement" type="bs:OldCustomType" />
</xs:schema>
and main.xsd (which is the definition file you can reference to validate XML etc.):
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
xmlns="old-namespace"
targetNamespace="old-namespace"
xmlns:new="new-namespace">
<xs:import schemaLocation="new.xsd" namespace="new-namespace"/>
<xs:redefine schemaLocation="old.xsd">
...
<!-- Modifications go here -->
...
</xs:redefine>
</xs:schema>
However I now need to similarly extend the original schema's WADL, also generated from the EA model. It would also be preferable to have an EA model to generate documentation etc. if possible, hence I'm trying to replicate the same schema functionality in EA. Unfortunately I'm not sure that the matching solution is possible in EA as this link indicates that the redefine XML schema construct has not been implemented in EA.
I was wondering if anyone has any alternative ways of achieving the same import-redefine type of functionality in EA (i.e. that doesn't rely on redefine)?

Enterprise Architect's XSD generator generates ref attribute instead of name attribute

Using the XML Schema toolbox, I have created the following diagram:
After generating the XSD, I get the following result:
Please note that the association is represented by
<xs:element ref="lib:Author" >
Instead, I would like to have:
<xs:element name="author" type="lib:Author" >
How should I change the model to achieve this in Enterprise Architect?
The solution is to add a tagged value 'anonymousRole=false' to the association, as follows:
Alternatively, this setting can be made at a global level, as a package property:

Add scenario to context in xbrl instance using jaxb

I have generated Java classes for my xbrl taxonomy using xjc. Now I am trying to marshall an xbrl instance. I am able to create scenario tag inside context. But can't find any Java class for adding explicit/typed member. Do I need to add any binding class for the same?
I'm new to jaxb.
Appreciate any help.
The issue may be that the elements you are referring to, xbrli:scenario and xbrldi:typedMember/xbrldi:explicitMember, are in two different schemas: the former is in the core XBRL schema, while the latter are in the XBRL dimensions-in-instance schema. This is because they came later as an extension to XBRL's segments.
If only the first schema is in scope (e.g., compiled with xjc), the xbrli:segment element can contain anything from other namespaces, as you can see here:
<element name="segment">
<complexType>
<sequence>
<any namespace="##other"
processContents="lax"
minOccurs="1"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
You need the second schema as well to be aware of the other two tags or create them.
Having said that, I am am not familiar with JAXB enough to tell if it supports this ##other construct natively, but I hope it helps you further. I would think that if the xbrldi schema is in the DTS, then there should be Java classes corresponding to it.

XML Schema Types

If I have an element, animal:
<animal name="dog"/>
Which can take the following as values to the name attribute:
dog
cat
bird
$(ANY_STRING)
Where $(ANY_STRING) is a simple name, value substitution that some software will perform and validate later (ANY_STRING being literally any string). What would the XML Schema for this element look like? Restricting on the three known names is easy enough:
<xs:simpleType name="AnimalNames">
<xs:restriction base="xs:string">
<xs:enumeration value="dog"/>
<xs:enumeration value="cat"/>
<xs:enumeration value="bird"/>
</xs:restriction>
</xs:simpleType>
Restricting on $(ANY_STRING) is similarly easy on its own (using xs:pattern to restrict). But since attributes may only be simple types, is it possible to specify that the attribute may be in the list of enumerations or the $(ANY_STRING) value?
Another option I've considered is restricting on the below pattern:
<xs:pattern value="dog|cat|bird|$(.*)"/>
Although that gets pretty nasty as the list of possible values grows.
Of course, the simplest option is to just declare a string type, but I'd like to be more restrictive than that.
One way to define semi-closed lists like this, with a set of well-known values explicitly specified for documentation, and then with an escape-hatch to allow other strings as well, is to define your attribute with a union of your AnimalNames type and xs:NMTOKEN or xs:Name (or whatever built-in or user-defined type best captures your constraints on the other names not enumerated).
As guidot points out in his comment, such a union accepts the same set of values as its most inclusive member type, so for schemas whose sole purpose is gatekeeping it's pointless. The technique is useful for documentation and for type-driven dispatch (if the validating member type is AnimalNames do X else do Y).
In order to accommodate schema validators that don't provide information about which member type validated a particular value of a union type, some vocabulary designers do as guidot suggests, and provide two element types, one for known / predicted / expected animal names and one for other names. Or they specify the type AnimalNames as accepting the strings dog, cat, bird, and other, define the attribute name as having type AnimalNames, and define another attribute (call it other-name) which is defined as having meaning if and only if name="other". So dogs are described using
<animal name="dog"/>
and hamsters with
<animal name="other" other-name="hamster"/>
That makes it fairly simple to handle the well known names specially while still accepting other names.

Is xml:lang allowed on element declared in schema as xs:string?

Given the following schema
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://tempuri.org/foo"
elementFormDefault="qualified">
<xs:element name="foo" type="xs:string" />
</xs:schema>
Is the following XML valid?
<foo xmlns="http://tempuri.org/foo" xml:lang="en-US">test</foo>
That is, is the "xml:lang" attribute allowed here?
The reason for this question is that WCF (Windows Communication Foundation) endpoints configured to use SOAP/1.1 over HTTP (basicHttpBinding in WCF terms) always includes the "xml:lang" attribute on the "faultstring" element when a fault is raised. According to the SOAP/1.1 envelope schema this element is of the simple type "xs:string".
I wouldn't really care if it wasn't for a customer ours is having problems deserializing these faults. I have reported this as a potential bug to Microsoft but got the response that this is by design and that it is conformant to SOAP/1.1. Reading XML Schema specifications leads me to believe that Microsoft is wrong and that no attributes are allowed on elements of simple types.
Am I missing something here related to attributes in the "xml:" namespace?
What I really would like to have is some sort of "official" definition that allows me to say "you're wrong" to Microsoft or "you have a buggy WS stack" to our customer without making a fool of myself.
EDIT: The answer to the title question seems to be "no" as stated below. The resolution to my WCF problem turned out to be pretty simple as well. Pass the empty string as the xmlLang parameter in the constructor of the System.ServiceModel.FaultReasonText and the attribute won't be added. Passing null doesn't work (ArgumentNullException) and neither does the one argument constructor (the system default language will be set as xml:lang)
According to XML Schema, O'reilly, from Eric van der Vlist, p. 170 (XML Attributes), the xml:lang attribute need to be declared in schema, with declared xml namespace and import a schema for xml namespâces.

Resources