views:

24

answers:

2

Hello,

I'm looking for a variant of choosing an attribute for an element, that can be directly set or be referenced.

this is what I have in Mind:

<root>    
<element>
   <attribute ref="shortname" />
</element>
<element>
   <attribute name="shortname" isEditable="true" anotherattrib="0815" />
</element>
</root>

Since this wouldn't be problem without an xml scheme, the definition of this attribute is quite hard if attribute "name" of element attribute is required.

the scheme could look like this

<xs:element name="attribute">
<xs:complexType>
<xs:attribute name="ref" use="required" />
<xs:attribute name="name" use="required" />
</xs:complexType>
</xs:element>

Is there any possibility to make a choice ( similar to a xs:choice for elements ) between attributes? Like if there is an attribute from element attribute named ref, no other attributes are allowed. if not, the attribute "name" must be set...

This problem sounds pure virtual and academic but I would be happy if there might be a solution or if I'm completely wrong with what I have in mind :)

Thank you in advance for any help!

Dave

A: 

It seems to me that it is impossible to define XML Schema like you want. Either you should define two different element names like <attribute> and <attributeRef> with the different set of mandatory attributes or you should define neither "ref" nor "name" attribute as "required".

XML Schema is not the only way to verify the data and you can not define some roles between the attribute values with respect of XML Schema. So if you do need verify more complex relationship in a XML document you can use XPath and XSLT to do this (see Schematron, XML Schema Language Comparison, Beyond W3C XML Schema, Improving XML Document Validation with Schematron, Advanced XML validation and Using XSL as a Validation Language).

Oleg
I think that the only way to express this it would be: declare a complex type with full content, declare two derive types with restriction, when declaring the parent content use a choice.
Alejandro
@Alejandro: In the way you can declare two types. It is not a problem, but how you can define a choice with two element with **the same name** "<attribute>" and different type? I am not sure that it will be possible. It seems to me you will receive the error that the definition of the element "<attribute>" is ambigous.
Oleg
@Oleg: The choice is between two elements (each one with a distinct derived type) but the same name, **in the parent declaration**, as example: complexType named `Base`; complexType named `BaseA` derived from `Base` with restrictions; the same for complexType named `BaseB`; element name `Parent` with a choice between an element named `Child` with `BaseA` type or an element named `Child` with `BaseB` type.
Alejandro
@Alejandro: Sorry, but I don't understand why you write a comment and not an answer on the question. If I create an XML Schema in Visual Studio 2010 and try to write `<xs:choice><xs:element name="attribute" type="baseAType"/><xs:element name="attribute" type="baseBType"/></xs:choice>` I receive an error about ambigous declaration of the element `<attribute>` like I wrote you before. It is not important whether `baseAType` and `baseBType` are child from the same parent. I have the error **always**. If you do think that you have a solution just write your answer with the corresponding schema.
Oleg
@Oleg: I write a comment begining with **I think that**. Then your answer was **I am not sure that it will be possible**. After that it seems you've tested it. So, the doubt was clear. And that's why this was a comment.
Alejandro
@Alejandro: I prefer to write always "I think that" and "I am not sure that it will be possible", because I can not be 100% sure that something is impossible. Just I could not find a way. For example one could probably define a schema in another way as I used. Visual Studio 2010 can also has a bug. So many things are possible. It is much easier to verify whether a solution work as to prove that something is impossible.
Oleg
A: 

Thanks for your answer. This is what I expected...

Dave

Dave