Validation issues

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Validation issues

jgagnon
This post was updated on .
I have written an application that generates XML files that represent test cases for a collection of types defined by an XML schema.  Some of these types contain elements that are abstract.  The logic locates all concrete implementers of the abstract type and when an instance is generated, processes one of the concrete types in place of the abstract type.

It's my understanding that the element must have a type reference attribute that indicates the concrete type name.  So, as an example:

...
  <SomeElement xsi:type="ConcreteType">
    ... content ...
  </SomeElement>
...

The schema defines the SomeElement field as being defined by an abstract type.  ConcreteType is one of many possible concrete implementers of that abstract type.

To take this a little further, a namespace entry is made in the document that defines a prefix for the schema types.  So, in the root element there would be entry like:

<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:myPrefix="http://my-schema-site"/>

The prefix is applied to all elements that are defined by the schema.  E.g. <myPrefix:SomeElement>.  I would also assume that the prefix needs to be used in the concrete type reference. So, what I have above now becomes:

...
  <myPrefix:SomeElement xsi:type="myPrefix:ConcreteType">
    ... content ...
  </myPrefix:SomeElement>
...

My application does all of this.

I have also added the option to validate the instance once it's been generated.  Here is where the problem enters the story.  For some reason, it fails validation with the complaint:

error: cvc-elt.4.2: Invalid xsi:type qname: 'myPrefix:ConcreteType' in element SomeElement@my-schema-site

Oddly, if I validate the instance externally using XMLBeans validate utility (.../xmlbeans-2.6.0/bin/validate), there is no complaint.

Am I doing something wrong?
Reply | Threaded
Open this post in threaded view
|

Re: Validation issues

Michael Pigott
Hi,
   Perhaps you are using the wrong prefix for the "type" element?  In my (valid) XML Schema, I do not define a prefix for the type attribute, and instead have the default namespace as http://www.w3.org/2001/XMLSchema.  Perhaps that's the difference?
   Eclipse also seems to come bundled with an XML Schema validator.  That gave me a lot of (painfully cryptic, but correct) error messages when I tried to define my own schema.

Good luck!
Mike


On Wed, Jul 16, 2014 at 1:15 PM, jgagnon <[hidden email]> wrote:
I have written an application that generates XML files that represent test
cases for a collection of types defined by an XML schema.  Some of these
types contain elements that are abstract.  The logic locates all concrete
implementers of the abstract type and when an instance is generated,
processes one of the concrete types in place of the abstract type.

It's my understanding that the element must have a type reference attribute
that indicates the concrete type name.  So, as an example:

...
  <SomeElement xsi:type="ConcreteType">
    ... content ...
  </SomeElement>
...

The schema defines the SomeElement field as being defined by an abstract
type.  ConcreteType is one of many possible concrete implementers of that
abstract type.

To take this a little further, a namespace entry is made in the document
that defines a prefix for the schema types.  So, in the root element there
would be entry like:

<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:myPrefix="http://my-schema-site"/>

The prefix is applied to all elements that are defined by the schema.  E.g.
<myPrefix:SomeElement>.  I would also assume that the prefix needs to be
used in the concrete type reference. So, what I have above now becomes:

...
  <SomeElement xsi:type="myPrefix:ConcreteType">
    ... content ...
  </SomeElement>
...

My application does all of this.

I have also added the option to validate the instance once it's been
generated.  *Here is where the problem enters the story.*  For some reason,
it fails validation with the complaint:

error: cvc-elt.4.2: Invalid xsi:type qname: 'myPrefix:ConcreteType' in
element SomeElement@my-schema-site

Oddly, if I validate the instance externally using XMLBeans validate utility
(.../xmlbeans-2.6.0/bin/validate), there is no complaint.

Am I doing something wrong?




--
View this message in context: http://xmlbeans.996285.n3.nabble.com/Validation-issues-tp7520.html
Sent from the XMLBeans User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Validation issues

Peter Keller-2
In reply to this post by jgagnon
Dear Joseph,

On Wed, 2014-07-16 at 10:15 -0700, jgagnon wrote:

> I have written an application that generates XML files that represent test
> cases for a collection of types defined by an XML schema.  Some of these
> types contain elements that are abstract.  The logic locates all concrete
> implementers of the abstract type and when an instance is generated,
> processes one of the concrete types in place of the abstract type.
>
> It's my understanding that the element must have a type reference attribute
> that indicates the concrete type name.  So, as an example:
>
> ...
>   <SomeElement xsi:type="ConcreteType">
>     ... content ...
>   </SomeElement>
> ...
>
> The schema defines the SomeElement field as being defined by an abstract
> type.  ConcreteType is one of many possible concrete implementers of that
> abstract type.
>
> To take this a little further, a namespace entry is made in the document
> that defines a prefix for the schema types.  So, in the root element there
> would be entry like:
>
> <Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:myPrefix="http://my-schema-site"/>
>
> The prefix is applied to all elements that are defined by the schema.  E.g.
> <myPrefix:SomeElement>.  I would also assume that the prefix needs to be
> used in the concrete type reference. So, what I have above now becomes:
>
> ...
>   <SomeElement xsi:type="myPrefix:ConcreteType">
>     ... content ...
>   </SomeElement>
> ...
>
> My application does all of this.
>
> I have also added the option to validate the instance once it's been
> generated.  *Here is where the problem enters the story.*  For some reason,
> it fails validation with the complaint:
>
> error: cvc-elt.4.2: Invalid xsi:type qname: 'myPrefix:ConcreteType' in
> element SomeElement@my-schema-site

IIRC XMLBeans implements XMLSchema 1.0 rather than 1.1, so this error
refers to clause 4.2 of this validation rule:

<http://www.w3.org/TR/xmlschema-1/#cvc-elt>

It looks as if the XML schema definition of myPrefix:ConcreteType is not
found or not accessible. Earlier you wrote:

> The logic locates all concrete implementers of the abstract type

This may be the problem: if by "concrete implementers" you mean types
defined in Java that simply implement/extend XMLBeans-generated types,
your implementing types have no presence within the schema type system
that XMLBeans generates. You have not stated explicitly whether or not
your concrete types are defined in XML schemata or not. If not, there is
no way that XMLBeans can know about them. If this is what you are doing,
you need to generate additional XML schemata that define your concrete
types (overriding the abstract types that are defined in your existing
XML schema by either restriction or extension). Compile these schemata
and the XMLBeans-generated API should allow you to work with the
concrete types, including instantiating them automatically and correctly
from parsed XML. On output, the xsi:type elements will also be written
automatically by the XMLBeans-generated API without you having to worry
about them.

Alternatively, you could generate your own implementations of
<http://xmlbeans.apache.org/docs/2.6.0/reference/org/apache/xmlbeans/SchemaType.html> and <http://xmlbeans.apache.org/docs/2.6.0/reference/org/apache/xmlbeans/SchemaTypeSystem.html>. This seems to me to be a much harder approach, although it may be worthwhile if you absolutely have to map existing Java types to XML Schema types.

> Oddly, if I validate the instance externally using XMLBeans validate utility
> (.../xmlbeans-2.6.0/bin/validate), there is no complaint.

Did you do 'validate -strict'?

> Am I doing something wrong?

Without knowing more about what you are doing, it is hard to say. FWIW,
I do something very like this (defining all my concrete types in XML
schemata) and I don't have any validation problems.

Hope that this helps,
Peter.

--
Peter Keller                                     Tel.: +44 (0)1223 353033
Global Phasing Ltd.,                             Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Validation issues

jgagnon
Sorry for the confusion.  My application does not deal with the Java implementation of any of the schema types.  It uses the information from the schema to determine test cases to generate and then uses the XMLBeans API (mainly XmlCursor) to create an XML instance.  Once the instance is complete I then validate it via the XmlObject.validate(XmlOptions options) method and save the object to a file.

One of the first things I do is to compile the schema XSD (with XmlBeans.compileXsd(...)) to get a SchemaTypeSystem object. This provides me with everything else I need.

The schema defines several abstract types, each of which has some number of other schema types that extend them (i.e. <xs:extension base="myPrefix:AbstractBaseType">).  As the program works its way through a document type to identify and generate test cases, when it encounters an element defined by an abstract type, it scans the schema for any types that extend that type.  It then generates the element with the type reference attribute to point to the specific concrete schema type.  I also generate the child content that is defined by the specific concrete type.

The generation logic inserts the namespace(s) as attributes of the root element.  I insert the "default" namespace (i.e. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance") and the schema-specific namespace (e.g. xmlns:myPrefix="my-schema-site") ["myPrefix" and "my-schema-site" are not the actual values used, of course].

As I mentioned, if I validate this using the XMLBeans command line validator, there is no complaint, but when I used the API validator, I get the error shown.

Regarding your comment on the schema version that is used, what can I do about that?  I insert the "standard" XML heading into the file before validating and saving.  E.g. <?xml version="1.0" encoding="utf-8"?>  Does the version number here indicate the schema version number?
Reply | Threaded
Open this post in threaded view
|

Re: Validation issues

Peter Keller-2
On Mon, 2014-07-21 at 05:50 -0700, jgagnon wrote:

> Sorry for the confusion.  My application does not deal with the Java
> implementation of any of the schema types.  It uses the information from the
> schema to determine test cases to generate and then uses the XMLBeans API
> (mainly XmlCursor) to create an XML instance.  Once the instance is complete
> I then validate it via the XmlObject.validate(XmlOptions options) method and
> save the object to a file.
>
> One of the first things I do is to compile the schema XSD (with
> XmlBeans.compileXsd(...)) to get a SchemaTypeSystem object. This provides me
> with everything else I need.
>
> The schema defines several abstract types, each of which has some number of
> other schema types that extend them (i.e. <xs:extension
> base="myPrefix:AbstractBaseType">).  As the program works its way through a
> document type to identify and generate test cases, when it encounters an
> element defined by an abstract type, it scans the schema for any types that
> extend that type.  It then generates the element with the type reference
> attribute to point to the specific concrete schema type.

OK - by "generates .. with the type reference..." do you mean that you
are doing something like this?

  xmlCursor.insertAttributeWithValue("type",
      "http://www.w3.org/2001/XMLSchema-instance",
      "myPrefix:ConcreteType");

If so, it seems to me that at this point the XMLBeans API hasn't
associated "myPrefix:" with your namespace, hence the validation
failure. The cursor methods can only work with attribute values of type
java.lang.String, i.e. as far as I can see the XmlCursor API doesn't
provide a bridge between attribute _values_ and anything related to the
schema. What you actually want to insert as the attribute value is an
instance of javax.xml.namespace.QName or org.apache.xmlbeans.XmlQName
rather than a string, but it doesn't seem that there is a way of doing
that.

When the document is read back in by the command-line validator, it
interprets the value of the xsi:type attribute as a QName, so it
validates OK.

> I also generate
> the child content that is defined by the specific concrete type.
>
> The generation logic inserts the namespace(s) as attributes of the root
> element.  I insert the "default" namespace (i.e.
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance") and the
> schema-specific namespace (e.g. xmlns:myPrefix="my-schema-site") ["myPrefix"
> and "my-schema-site" are not the actual values used, of course].

I work with documents that are very similar to yours without any
problems. There are two differences with what you are doing:

(i) I don't use XmlCursor, but rather the type-specific methods provided
by the XMLBeans-generated API, something like this:

  Instantiate an element of the correct type like this:

    myConcreteType = ConcreteType.Factory.newInstance();

   then populate it and insert it into the XML instance something like
this:

  myContainingElement.setSomeElement(i, myConcreteType);

I don't set the type reference at all, it is just taken care of
automatically by the XMLBeans-generated API.

If this is not practical for you, then perhaps saving and re-parsing the
XML instance before validating would be an acceptable workaround?

(ii) the xmlns:xsi and xmlns:myprefix attributes end up in the element
that is the immediate container of the explicitly typed element rather
than the root element:

 <ContainingElement xmlns:xsi="..." xmlns:myprefix="...">
   <TypedElement xsi:type="myprefix:MyType">
  ...
  </TypedElement>
 </ContainingElement>

or sometimes on the typed element itself. This is a minor annoyance, and
in my hands XmlObject.setSaveAggressiveNamespaces() has no effect when
the document is saved, but it really shouldn't make any difference to
the validation.

> Regarding your comment on the schema version that is used, what can I do
> about that?  

A version 1.0 schema is still valid under the 1.1 standard: I mentioned
it only in order to be clear about which standards document I was using
to look up your error message (the clause numbers are different in the
two standards). As far as I know, if you use XMLBeans, you are using XML
Schema 1.0. Only you can decide whether that is a problem for you (it
isn't for me, FWIW). The introduction to the XML Schema 1.1 document may
be a good starting point:

<http://www.w3.org/TR/xmlschema11-1/#intro1.1>

> I insert the "standard" XML heading into the file before
> validating and saving.  E.g. <?xml version="1.0" encoding="utf-8"?>  Does
> the version number here indicate the schema version number?

No, this is the version of the XML standard that is used, not of XML
Schema. Once again, only you can decide whether you have a need for XML
1.1, or if 1.0 is OK for you. As with XML Schema, there is a preamble to
the newer standard that says something about what issues it is
addressing:

<http://www.w3.org/TR/xml11/#sec-xml11>

Regards,
Peter.

--
Peter Keller                                     Tel.: +44 (0)1223 353033
Global Phasing Ltd.,                             Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]