Re: Validation issues

2014-07-21 Thread Peter Keller
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: user-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: user-h...@xmlbeans.apache.org



Re: Validation issues

2014-07-21 Thread 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?



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

-
To unsubscribe, e-mail: user-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: user-h...@xmlbeans.apache.org



Re: Validation issues

2014-07-21 Thread Peter Keller
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.,   

Re: Validation issues

2014-07-20 Thread 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 joseph.gag...@ll.mit.edu 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: user-unsubscr...@xmlbeans.apache.org
 For additional commands, e-mail: user-h...@xmlbeans.apache.org