Xsd - xml must contain element with specific attribute value

[Jaguex]

Hi,
I have the following 3rd party xml which has to be validated:

<Items>
<Item Id="1" Value=""/>
<Item Id="2" Value="someValue"/>
<Item Id="3" Value="someOtherValue"/>
</Items>
 

For later transformation (xslt) it is required that item Id=2 exists and its attribute Value may not be emptyString. All other items can and must be ignored since the set items can be enlarged or diminished in the future.
Is this possible with xsd? any clues?

Your help would greatly be appreciated!

[Dormilich]

I'm not sure if all your requirements are possible…

what you can do is
- force an attribute to be present (regardless of its content)
- same as above + define the type (string/number/…) of its content
- you can force a (one) specific content value (or a selection thereof) to be used

XML Schema Specification

you can "omit" the other elements by using the ANY declaration.

[Jaguex]

Hi Dormilich, thanx for your reply.

The structure of the xml is indeed easily validated with xsd as are type and content values with patterns or restrictions.
I can't get the "any" declaration to work tho since i have to declare element item in order to validate its structure and the any would allow "item" resulting in a conflict.


Thusfar I am considering 2 options for the problem:
Xpath but I am not sure it can be done in xsd: e.g. Items/Item[@Id='2'] != null
still googling about this option ;)

Using Xslt to transform xml first so only item[@Id='2'] remains in the xml and then applying the scheme.

[Dormilich]

@Jaguex
If you're doing that, there's no need to validate the result, just let return the the content and check the result.

say,

//item[@Id='2']/@Value

if this returns some text (i.e. not the empty string or empty node-set), your requirement was fulfilled. you only need to make sure "Id" is a ID type attribute.

[Jaguex]

You are right but I forgot to mention that this is a bit in a recursive xml structure. It would be far more easy to transform first regardless and than validate. the Xml has to be imported and the process has to stop further transformations, db storage if the file is not valid. Ofcourse after informing the uploading user.

But, I prefer to do all validation in a scheme: xsd and existence of item[@Id=2] seems to me part of validation not of transformation. Do you have any clues how to intergrate such kind of xpath expression within the xsd?

Maybe I should break the problem into 2:
1) Exists(Item[@Id='2']
2] Exists(Item[@Id='2' and @Value != '']

Can any of the two be solved within xsd?
Cheers J.

[Dormilich]

if you indeed transform the XML first, then you can easily apply an XSD. your Id can only have the value 2 (otherwise the XSLT is faulty), there must be only one such element and you should be able to check for a content in Value.

but I'm not aware, that XSD is capable of XPath (well, why should it?)

[Jaguex]

Xsd is capable of xpath to validate key integrity (constraints)
It seems to me an essential part of validation of structure.

Therefor it would be strange if xsd is not capable to check on a External Id being present in the document .. I still didn't figure out how to "hack" this :)

[Jaguex]

It can not be done in xsd. It lacks full Xpath support. :(

http://www.xml.com/pub/a/2002/04/10/beyondwxs.html

The solution is to apply xslt to validate complex constraints.
I hope this is integrated into xsd very soon! So I don't need to transform/evaluate a document twice.

I opt for first Xslt and then Xsd validation.
Use the xslt for transforming to constrained xml and then validate this xml with the xsd in order to know weather or not the constraints are all valid.
Doing xslt first, will allow the removal of all redundant data before validation.

e.g.

Xslt

 <items>
    <xsl:copy-of select="/Items/Item[@Id='2' and @Value != '']/>
 <items>
 

Xsd

 
  <xs:element name="Items">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="Item">
          <xs:complexType>
            <xs:attribute name="Id" type="xs:positiveInteger" use="required" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
 

[Dormilich]

if you do the XSLT by means of a script/programming language (C, Java, PHP to name some) you can simplify that by checking the result of the XSLT, because the XSLT already contains your constraints… or did I misunderstand something there?

[Jaguex]

You are quite right.. but if the xml is quite large it would be nice to immediately strip all redundancy in the first step. So my xslt would produce a constrained xml for further processing instead of an error list.
Eg. item id= 2 is only copied when exists and value != '' and all items with other id's are discarded.

I would continue to work with this non-redundant constrained xml. Remember it has to be transformed again. Also saves a lot of diskspace when it needs to be stored ;)

Tho xslt will produce a constrained xml it might be incosistent in format.. thus it has to be checked for proper format by means of xsd. Eg item id=2 still has to be present throughout document before proceding!

But this is just the way I think about addressing the problem.
Otherwise what is the point of having xsd at all? All can be done through xslt!