RE: Namespace prefix throws spanner in works

2005-05-23 Thread Adam Hardy
A question about xmlbeans: if I change the schema locally and compile my
xmlbeans into a jar, is that elementFormDefault attribute ( all schema
info) compiled into my jar, or will xmlbeans validate() try to reference
the schema again?

In my current set-up in Eclipse, I am certain that the app is not
accessing the schemas once running. 


Thanks
Adam



 -Original Message-
 From: Lawrence Jones [mailto:[EMAIL PROTECTED] 
 Sent: 20 May 2005 17:44
 To: user@xmlbeans.apache.org
 Subject: RE: Namespace prefix throws spanner in works
 
 
 Hi Adam
 
 Without seeing the schema in full it's hard to tell, but 
 here's my guess. I guess that you've declared the 
 mediumName element as a local element in the schema (this 
 will happen if it is not an immediate child of the top-level 
 schema element).
 
 How you refer to local elements and specifically whether you 
 should include a namespace prefix or not is controlled by the 
 form attribute on the element's declaration in the schema. If 
 the form attribute is missing then it's controlled by the 
 elementFormDefault attribute on the surrounding schema 
 element. The default in both these cases (and therefore what 
 will happen if they are both missing) is unqualified. This 
 means that local elements _must_ be referred to without a 
 namespace. I'm guessing that this is what has happened in your case.
 
 If the form value is unqualified then it is an error to 
 refer to the local element using a namespace prefix and the 
 validator correctly points this out.
 
 It sounds like you have control over the schema. If so then 
 you can change it so that either that specific element 
 declaration has form=qualified or you can set the same rule 
 for the whole schema by setting 
 elementFormDefault=qualified in the schema element instead.
 
 Note that it is equally an error for you to be expecting a 
 namespace and not to see one - so if you update your schema 
 in this way be sure that all clients know about it and will 
 ensure that all local elements are namespace qualified in all 
 the instance documents.
 

http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. 
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. 
Further communication will signify your consent to this.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Resent: xs:all fails to validate minOccurs='0'

2005-05-23 Thread Saha, Sanjeev








For schema:




xs:complexType name=Invoice_Type


xs:all


xs:element
name=InvoiceNum type=INV_NO_Type minOccurs=0/


xs:element
name=InvoiceClass type=INV_CLASS_Type/


xs:element
name=Warehouse type=WARE_NO_Type/


/xs:all


/xs:complexType



Where INV_NO_Type is defined as an Integer, I get the following error if I leave out
the InvoiceNum/ tag from the XML.



java.lang.Exception: Xml NOT valid for the following
reason(s):


error: Expected element InvoiceNum at the end of the content in element Invoice





However, if I replace xs:all/ with
xs:sequence/ it seems to work without any problem. Any clues anyone?



Regards, 
Sanjeev












RE: Namespace prefix throws spanner in works

2005-05-23 Thread Lawrence Jones
Hi Adam

Re your question on which elementFormDefault applies (1) or (2) -
unfortunately for you it's the one in the schema element surrounding the
local declaration of mediumName in the scheduleNameGroup model group
definition. So the unqualified treatment required by (2) is correct.

I have some sympathy with your other comments as I prefer the
elementFormDefault=qualified setup myself. But having said that,
elementFormDefault=unqualified is not illegal. And it's not as if the
attribute has been forgotten (and therefore defaulted); rather the
schema designers have explicitly chosen to make it unqualified.

It is the responsibility of whoever constructs the instance document to
conform to the schema so, technically, whoever is providing you with
your instance doc is providing invalid XML which should be rejected and
you should contact them to fix it. But if you're happy having your local
copy of the schema then so be it.

Cheers,

Lawrence

 -Original Message-
 From: Adam Hardy [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 23, 2005 2:57 AM
 To: user@xmlbeans.apache.org
 Subject: RE: Namespace prefix throws spanner in works
 
 The schemas are in public domain so I can edit neither the schema nor
 the incoming XML :(
 
 (1) http://www.worlddab.org/schemas/epg/epgSchedule_11.xsd
 (2) http://www.worlddab.org/schemas/epg/epgDataTypes_11.xsd
 
 
 You are correct about the elementFormDefault=unqualified on the
 imported schema (2), however in the actual schema (1) it is set to
 qualified, which would be this element's 'surrounding schema'. Does
 this make no difference?
 
 As far as my project is concerned, I can keep a local copy of the
schema
 and change that elementFormDefault. That will sort out my xml beans
 validation.
 
 Truth be told this is actually the second change we have to make to
the
 schema, which points a finger at the WorldDAB committee who wrote it.
I
 did email them when I had to make the first change but received no
 reply. Oh well.
 
 Thanks for the help :)
 
 
 Adam
 
 
 
 
 
  -Original Message-
  From: Lawrence Jones [mailto:[EMAIL PROTECTED]
  Sent: 20 May 2005 17:44
  To: user@xmlbeans.apache.org
  Subject: RE: Namespace prefix throws spanner in works
 
 
  Hi Adam
 
  Without seeing the schema in full it's hard to tell, but
  here's my guess. I guess that you've declared the
  mediumName element as a local element in the schema (this
  will happen if it is not an immediate child of the top-level
  schema element).
 
  How you refer to local elements and specifically whether you
  should include a namespace prefix or not is controlled by the
  form attribute on the element's declaration in the schema. If
  the form attribute is missing then it's controlled by the
  elementFormDefault attribute on the surrounding schema
  element. The default in both these cases (and therefore what
  will happen if they are both missing) is unqualified. This
  means that local elements _must_ be referred to without a
  namespace. I'm guessing that this is what has happened in your case.
 
  If the form value is unqualified then it is an error to
  refer to the local element using a namespace prefix and the
  validator correctly points this out.
 
  It sounds like you have control over the schema. If so then
  you can change it so that either that specific element
  declaration has form=qualified or you can set the same rule
  for the whole schema by setting
  elementFormDefault=qualified in the schema element instead.
 
  Note that it is equally an error for you to be expecting a
  namespace and not to see one - so if you update your schema
  in this way be sure that all clients know about it and will
  ensure that all local elements are namespace qualified in all
  the instance documents.
 
  Cheers,
 
  Lawrence
 
   -Original Message-
   From: Adam Hardy [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 20, 2005 6:08 AM
   To: user@xmlbeans.apache.org
   Subject: Namespace prefix throws spanner in works
  
   Hi,
  
   I hope someone give me a clue how to proceed with this issue: I
 compiled
   a set of beans against my schema and now I'm using them in my app.
  
   I parse an XML doc into the document, and then when I call
   doc.validate(), I get a series of validation errors.
  
   My xml header looks like this:
  
   ?xml version=1.0 encoding=UTF-8?
   epg xmlns:epg=http://www.worlddab.org/schemas/epg;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=http://www.worlddab.org/schemas/epg
   epgSchedule_11.xsd
 system=DAB
   Etc etc
  
   And the xml where the first error occurs looks like this:
  
   programme shortId=59033
 epg:mediumNamePM/epg:mediumName
 [snip...]
   /programme
  
   And the error says:
  
   Expected element mediumName at the end of the content in element
   programme
  
   If I remove the epg: namespace prefix from the elements, then it
   validates fine, but I can't do that in the live environment - the
 app
   

RE: Namespace prefix throws spanner in works

2005-05-23 Thread Lawrence Jones
Hi Adam

scomp has an option, -dl, which will download included and imported
schemas from the network. In the absence of this option no network
downloads take place and it searches for includes and imports locally.
I'm not sure of the details of exactly how this works but if you are
compiling successfully without the -dl option then it is correctly
finding the imported schema from somewhere local.

All the details of the infoset, including the information about the
namespace against which to validate instance docs, are included in the
.xsb files which are part of what gets generated in the jar. So when you
run validate() on an XmlBean you are comparing the instance to the
information in the .xsb's which in your case were compiled from the
local schema.

Cheers,

Lawrence

 -Original Message-
 From: Adam Hardy [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 23, 2005 3:19 AM
 To: user@xmlbeans.apache.org
 Subject: RE: Namespace prefix throws spanner in works
 
 A question about xmlbeans: if I change the schema locally and compile
my
 xmlbeans into a jar, is that elementFormDefault attribute ( all
schema
 info) compiled into my jar, or will xmlbeans validate() try to
reference
 the schema again?
 
 In my current set-up in Eclipse, I am certain that the app is not
 accessing the schemas once running.
 
 
 Thanks
 Adam
 
 
 
  -Original Message-
  From: Lawrence Jones [mailto:[EMAIL PROTECTED]
  Sent: 20 May 2005 17:44
  To: user@xmlbeans.apache.org
  Subject: RE: Namespace prefix throws spanner in works
 
 
  Hi Adam
 
  Without seeing the schema in full it's hard to tell, but
  here's my guess. I guess that you've declared the
  mediumName element as a local element in the schema (this
  will happen if it is not an immediate child of the top-level
  schema element).
 
  How you refer to local elements and specifically whether you
  should include a namespace prefix or not is controlled by the
  form attribute on the element's declaration in the schema. If
  the form attribute is missing then it's controlled by the
  elementFormDefault attribute on the surrounding schema
  element. The default in both these cases (and therefore what
  will happen if they are both missing) is unqualified. This
  means that local elements _must_ be referred to without a
  namespace. I'm guessing that this is what has happened in your case.
 
  If the form value is unqualified then it is an error to
  refer to the local element using a namespace prefix and the
  validator correctly points this out.
 
  It sounds like you have control over the schema. If so then
  you can change it so that either that specific element
  declaration has form=qualified or you can set the same rule
  for the whole schema by setting
  elementFormDefault=qualified in the schema element instead.
 
  Note that it is equally an error for you to be expecting a
  namespace and not to see one - so if you update your schema
  in this way be sure that all clients know about it and will
  ensure that all local elements are namespace qualified in all
  the instance documents.
 
 
 http://www.bbc.co.uk/
 
 This e-mail (and any attachments) is confidential and may contain
 personal views which are not the views of the BBC unless specifically
 stated.
 If you have received it in error, please delete it from your system.
 Do not use, copy or disclose the information in any way nor act in
 reliance on it and notify the sender immediately. Please note that the
 BBC monitors e-mails sent or received.
 Further communication will signify your consent to this.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: good way of writing xs:any

2005-05-23 Thread Cezar Andrei
XmlCursor's copy and move methods can be used for this.


 -Original Message-
 From: Ali, Haneef [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 23, 2005 5:38 PM
 To: user@xmlbeans.apache.org
 Subject: RE: good way of writing xs:any
 
 Hi Steven,
 
 This is one area where the functionality of xmlbeans is limited
 
 Assume statusDetail is a complex element, in that case it is very
 difficult to insert the object. Idealy it would make life simpler if
 xmlcustor had
   insertXMLObject() besides insertChars().
 
 Eg:
  status xmlns=http://openuri.org;
 statusdetail
   s1
  s2text of status detail/s2
 /s1
 /statusDetail
 /status
 
 Though it can be done via xmlcursor , it is not trivial to create the
 above xml fragment if status is  defiend to have xsd:any.
 
 Regards,
 Haneef
 
 
 
 
 From: Steven Traut [mailto:[EMAIL PROTECTED]
 Sent: Monday, May 23, 2005 2:05 PM
 To: user@xmlbeans.apache.org
 Subject: RE: good way of writing xs:any
 
 
 Hello Argyn -- This is an area where you have to bypass the
 JavaBeans-style accessors generated by XMLBeans. Try using an
XmlCursor
 instance to insert the element.
 
 So, let's assume your schema defines a status element of StatusType
 that has a statusdetail element of type StatusDetailType as a child,
 and you want to insert a new statusdetail child. You might have
 something like this (er, roughly -- others jump in if I've got it
 wrong):
 
 StatusType status = StatusType.Factory.newInstance();
 XmlCursor cursor = status.newCursor();
 cursor.toLastAttribute();
 cursor.toNextToken();
 // Begin a new statusdetail element whose namespace URI is the
target
 URI of your schema (let's say http://openuri.org/).
 cursor.beginElement(statusdetail, http://openuri.org/;);
 // Insert text of status detail as an element value.
 cursor.insertChars(text of status detail);
 cursor.dispose();
 
 This should give you something like:
 
 status xmlns=http://openuri.org;
 statusdetailtext of status detail/statusdetail
 /status
 
 You might search the archives of this mailing list -- this question
has
 been asked a few times, and you may find an answer in one of the other
 responses.
 
 Also, see these topics in the docs for more on the cursor:
 

http://xmlbeans.apache.org/docs/2.0.0/guide/conNavigatingXMLwithCursors.
 html
 http://xmlbeans.apache.org/documentation/tutorial_getstarted.html
(under
 Getting Started with the XML Cursor)
 http://wiki.apache.org/xmlbeans/XmlBeansTutorial/MixedContent
 
 Steve
 
   -Original Message-
   From: Kuketayev, Argyn (Contractor)
 [mailto:[EMAIL PROTECTED]
   Sent: Monday, May 23, 2005 12:25 PM
   To: user@xmlbeans.apache.org
   Subject: good way of writing xs:any
 
 
   Here's a snippet of schema with xs:any element:
 
xs:complexType name=StatusDetailType
 xs:sequence
  xs:any namespace=##any processContents=lax minOccurs=0
 maxOccurs=unbounded/
 /xs:sequence
/xs:complexType
 
   XMLBeans generates StatusDetailType without any any children
 manipulation methods. What's the right way of adding a child element
to
 this element? My child element has Java class generated by XMLBeans
too.
 
   thanks,
   Argyn
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]