Home » Archived » XML Schema Definition (XSD) » Maximum content for <all> ??
|
Re: Maximum content for <all> ?? [message #32903 is a reply to message #32831] |
Mon, 10 November 2003 11:54 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
In order to validate the Unique Particle Attribute rule the XSD model builds a finite state
machine for each content model. Unfortunately a finite state machine for an <all> content
model with n alternatives has n! states. So in cases where the finite state machine is too
big to construct I put out a message to that effect. I really need to revisit this issue
eventually, and handle it more gracefully so you're welcome to open a bugzilla defect
requesting that; I probably won't have time to look at it for quite a while.
Hayden Marchant wrote:
> I was parsing a pretty simple xsd with the following complex type:
> <xsd:complexType name="PowerRequest">
> <xsd:all>
> <xsd:element name="power" type="xsd:string"/>
> <xsd:element name="page" type="xsd:string"/>
> <xsd:element name="mode" type="xsd:string"/>
> <xsd:element name="tag" type="xsd:string"/>
> <xsd:element name="type" type="xsd:string"/>
> <xsd:element name="devtag" type="xsd:string"/>
> <xsd:element name="sort" type="xsd:string" minOccurs="0"/>
> <xsd:element name="variations" type="xsd:string" minOccurs="0"/>
> <xsd:element name="locale" type="xsd:string" minOccurs="0"/>
> </xsd:all>
> </xsd:complexType>
>
> and I got the following message:
>
> Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> options is too large.
>
> Is this according to W3C spec or is it some kind of bug?
>
> Thanks,
|
|
| |
Re: Maximum content for <all> ?? [message #37915 is a reply to message #37816] |
Thu, 04 March 2004 16:46 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
Which version of XSD are you using?
Hayden Marchant wrote:
> We're having quite a performance issue with this problem at a client site.
> They have a schema with an <all> with more than 40 particles. Apparently
> they can go out for lunch while the schema is being parsed.
>
> Can you suggest any workaround for this? I have an ugly idea, which is
> pre-processing the schema to change the <all> to a <sequence>. This would
> be a temporary fix until this issue is resolved. What would be the best
> way to do that? I could do this rename through a URIConverter. Do you have
> any other ideas?
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In order to validate the Unique Particle Attribute rule the XSD model builds
> a finite state
> > machine for each content model. Unfortunately a finite state machine for an
> <all> content
> > model with n alternatives has n! states. So in cases where the finite state
> machine is too
> > big to construct I put out a message to that effect. I really need to
> revisit this issue
> > eventually, and handle it more gracefully so you're welcome to open a
> bugzilla defect
> > requesting that; I probably won't have time to look at it for quite a while.
>
> > Hayden Marchant wrote:
>
> > > I was parsing a pretty simple xsd with the following complex type:
> > > <xsd:complexType name="PowerRequest">
> > > <xsd:all>
> > > <xsd:element name="power" type="xsd:string"/>
> > > <xsd:element name="page" type="xsd:string"/>
> > > <xsd:element name="mode" type="xsd:string"/>
> > > <xsd:element name="tag" type="xsd:string"/>
> > > <xsd:element name="type" type="xsd:string"/>
> > > <xsd:element name="devtag" type="xsd:string"/>
> > > <xsd:element name="sort" type="xsd:string"
> minOccurs="0"/>
> > > <xsd:element name="variations" type="xsd:string"
> minOccurs="0"/>
> > > <xsd:element name="locale" type="xsd:string"
> minOccurs="0"/>
> > > </xsd:all>
> > > </xsd:complexType>
> > >
> > > and I got the following message:
> > >
> > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > options is too large.
> > >
> > > Is this according to W3C spec or is it some kind of bug?
> > >
> > > Thanks,
|
|
| |
Re: Maximum content for <all> ?? [message #38046 is a reply to message #37995] |
Mon, 08 March 2004 11:52 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
In version 2.0 we don't produce this warning anymore because we use an approximate
DFA to validate the unique particle attribution rule.
Hayden Marchant wrote:
> I'm currently using 1.1.1. We're are pretty advanced into release cycle
> and am a bit weary of upgrading eclipse at this stage. Obviously if a
> newer release of Eclipse solves this elegantly, then I can try to postpone
> this issue.
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Which version of XSD are you using?
>
> > Hayden Marchant wrote:
>
> > > We're having quite a performance issue with this problem at a client site.
> > > They have a schema with an <all> with more than 40 particles. Apparently
> > > they can go out for lunch while the schema is being parsed.
> > >
> > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > pre-processing the schema to change the <all> to a <sequence>. This would
> > > be a temporary fix until this issue is resolved. What would be the best
> > > way to do that? I could do this rename through a URIConverter. Do you have
> > > any other ideas?
> > >
> > > Thanks,
> > > Hayden
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In order to validate the Unique Particle Attribute rule the XSD model
> builds
> > > a finite state
> > > > machine for each content model. Unfortunately a finite state machine
> for an
> > > <all> content
> > > > model with n alternatives has n! states. So in cases where the finite
> state
> > > machine is too
> > > > big to construct I put out a message to that effect. I really need to
> > > revisit this issue
> > > > eventually, and handle it more gracefully so you're welcome to open a
> > > bugzilla defect
> > > > requesting that; I probably won't have time to look at it for quite a
> while.
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > <xsd:complexType name="PowerRequest">
> > > > > <xsd:all>
> > > > > <xsd:element name="power" type="xsd:string"/>
> > > > > <xsd:element name="page" type="xsd:string"/>
> > > > > <xsd:element name="mode" type="xsd:string"/>
> > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > <xsd:element name="type" type="xsd:string"/>
> > > > > <xsd:element name="devtag" type="xsd:string"/>
> > > > > <xsd:element name="sort" type="xsd:string"
> > > minOccurs="0"/>
> > > > > <xsd:element name="variations"
> type="xsd:string"
> > > minOccurs="0"/>
> > > > > <xsd:element name="locale" type="xsd:string"
> > > minOccurs="0"/>
> > > > > </xsd:all>
> > > > > </xsd:complexType>
> > > > >
> > > > > and I got the following message:
> > > > >
> > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > options is too large.
> > > > >
> > > > > Is this according to W3C spec or is it some kind of bug?
> > > > >
> > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #38239 is a reply to message #38046] |
Mon, 08 March 2004 15:44 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
Does this mean that in Version 2.0, both the performance problem and the
excessive warnings are resolved?
Thanks,
Ed Merks wrote:
> Hayden,
> In version 2.0 we don't produce this warning anymore because we use an
approximate
> DFA to validate the unique particle attribution rule.
> Hayden Marchant wrote:
> > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > newer release of Eclipse solves this elegantly, then I can try to postpone
> > this issue.
> >
> > Thanks,
> > Hayden
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Which version of XSD are you using?
> >
> > > Hayden Marchant wrote:
> >
> > > > We're having quite a performance issue with this problem at a client
site.
> > > > They have a schema with an <all> with more than 40 particles.
Apparently
> > > > they can go out for lunch while the schema is being parsed.
> > > >
> > > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > > pre-processing the schema to change the <all> to a <sequence>. This
would
> > > > be a temporary fix until this issue is resolved. What would be the best
> > > > way to do that? I could do this rename through a URIConverter. Do you
have
> > > > any other ideas?
> > > >
> > > > Thanks,
> > > > Hayden
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In order to validate the Unique Particle Attribute rule the XSD model
> > builds
> > > > a finite state
> > > > > machine for each content model. Unfortunately a finite state machine
> > for an
> > > > <all> content
> > > > > model with n alternatives has n! states. So in cases where the
finite
> > state
> > > > machine is too
> > > > > big to construct I put out a message to that effect. I really need
to
> > > > revisit this issue
> > > > > eventually, and handle it more gracefully so you're welcome to open a
> > > > bugzilla defect
> > > > > requesting that; I probably won't have time to look at it for quite a
> > while.
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > > <xsd:complexType name="PowerRequest">
> > > > > > <xsd:all>
> > > > > > <xsd:element name="power"
type="xsd:string"/>
> > > > > > <xsd:element name="page"
type="xsd:string"/>
> > > > > > <xsd:element name="mode"
type="xsd:string"/>
> > > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > > <xsd:element name="type"
type="xsd:string"/>
> > > > > > <xsd:element name="devtag"
type="xsd:string"/>
> > > > > > <xsd:element name="sort" type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > <xsd:element name="variations"
> > type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > <xsd:element name="locale"
type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > </xsd:all>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > and I got the following message:
> > > > > >
> > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > > options is too large.
> > > > > >
> > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > >
> > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #38338 is a reply to message #38239] |
Mon, 08 March 2004 16:32 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
I don't know about the peformance problem, you'll have to try it and see.
Hayden Marchant wrote:
> Does this mean that in Version 2.0, both the performance problem and the
> excessive warnings are resolved?
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In version 2.0 we don't produce this warning anymore because we use an
> approximate
> > DFA to validate the unique particle attribution rule.
>
> > Hayden Marchant wrote:
>
> > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > newer release of Eclipse solves this elegantly, then I can try to postpone
> > > this issue.
> > >
> > > Thanks,
> > > Hayden
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > Which version of XSD are you using?
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > We're having quite a performance issue with this problem at a client
> site.
> > > > > They have a schema with an <all> with more than 40 particles.
> Apparently
> > > > > they can go out for lunch while the schema is being parsed.
> > > > >
> > > > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > > > pre-processing the schema to change the <all> to a <sequence>. This
> would
> > > > > be a temporary fix until this issue is resolved. What would be the best
> > > > > way to do that? I could do this rename through a URIConverter. Do you
> have
> > > > > any other ideas?
> > > > >
> > > > > Thanks,
> > > > > Hayden
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > In order to validate the Unique Particle Attribute rule the XSD model
> > > builds
> > > > > a finite state
> > > > > > machine for each content model. Unfortunately a finite state machine
> > > for an
> > > > > <all> content
> > > > > > model with n alternatives has n! states. So in cases where the
> finite
> > > state
> > > > > machine is too
> > > > > > big to construct I put out a message to that effect. I really need
> to
> > > > > revisit this issue
> > > > > > eventually, and handle it more gracefully so you're welcome to open a
> > > > > bugzilla defect
> > > > > > requesting that; I probably won't have time to look at it for quite a
> > > while.
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > <xsd:all>
> > > > > > > <xsd:element name="power"
> type="xsd:string"/>
> > > > > > > <xsd:element name="page"
> type="xsd:string"/>
> > > > > > > <xsd:element name="mode"
> type="xsd:string"/>
> > > > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > > > <xsd:element name="type"
> type="xsd:string"/>
> > > > > > > <xsd:element name="devtag"
> type="xsd:string"/>
> > > > > > > <xsd:element name="sort" type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > <xsd:element name="variations"
> > > type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > <xsd:element name="locale"
> type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > </xsd:all>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > > and I got the following message:
> > > > > > >
> > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > > > options is too large.
> > > > > > >
> > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > >
> > > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #38439 is a reply to message #38338] |
Tue, 09 March 2004 08:41 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I didn't see that version 2.0.0 helped in performance so I'm going ahead
with a hack to try to speed up the validation since that is the problem
for <all>. I tried parsing and validating 2 very similar schemas - 1 with
<all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
the <sequence> took 1 minute.
I am trying to change the schema temporarily before validation, and then
change it back. The change that I am making is to change all the model
groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
am holding in memory. I have written the code and it is not speeding up
the validation the same way that a clean schema with <sequence> would. I
think that my changes are not being propogated through.
I am doing the following:
1. XSDSchema.setIncrementalUpdate(false);
2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
an ALL_LITERAL
3. XSDSchema.update();
4. XSDSchema.validate();
5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
that I changed.
6. XSDSchema.update().
The validation step at 4. is still taking ages. If I stick in a
XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
but I think that I have a step missing to really solve the problem.
Thanks,
Ed Merks wrote:
> Hayden,
> I don't know about the peformance problem, you'll have to try it and see.
> Hayden Marchant wrote:
> > Does this mean that in Version 2.0, both the performance problem and the
> > excessive warnings are resolved?
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > In version 2.0 we don't produce this warning anymore because we use an
> > approximate
> > > DFA to validate the unique particle attribution rule.
> >
> > > Hayden Marchant wrote:
> >
> > > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > > newer release of Eclipse solves this elegantly, then I can try to
postpone
> > > > this issue.
> > > >
> > > > Thanks,
> > > > Hayden
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > Which version of XSD are you using?
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > We're having quite a performance issue with this problem at a
client
> > site.
> > > > > > They have a schema with an <all> with more than 40 particles.
> > Apparently
> > > > > > they can go out for lunch while the schema is being parsed.
> > > > > >
> > > > > > Can you suggest any workaround for this? I have an ugly idea,
which is
> > > > > > pre-processing the schema to change the <all> to a <sequence>. This
> > would
> > > > > > be a temporary fix until this issue is resolved. What would be the
best
> > > > > > way to do that? I could do this rename through a URIConverter. Do
you
> > have
> > > > > > any other ideas?
> > > > > >
> > > > > > Thanks,
> > > > > > Hayden
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > In order to validate the Unique Particle Attribute rule the XSD
model
> > > > builds
> > > > > > a finite state
> > > > > > > machine for each content model. Unfortunately a finite state
machine
> > > > for an
> > > > > > <all> content
> > > > > > > model with n alternatives has n! states. So in cases where the
> > finite
> > > > state
> > > > > > machine is too
> > > > > > > big to construct I put out a message to that effect. I really
need
> > to
> > > > > > revisit this issue
> > > > > > > eventually, and handle it more gracefully so you're welcome to
open a
> > > > > > bugzilla defect
> > > > > > > requesting that; I probably won't have time to look at it for
quite a
> > > > while.
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > I was parsing a pretty simple xsd with the following complex
type:
> > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > <xsd:all>
> > > > > > > > <xsd:element name="power"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="page"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="mode"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="tag"
type="xsd:string"/>
> > > > > > > > <xsd:element name="type"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="devtag"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="sort"
type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > <xsd:element name="variations"
> > > > type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > <xsd:element name="locale"
> > type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > </xsd:all>
> > > > > > > > </xsd:complexType>
> > > > > > > >
> > > > > > > > and I got the following message:
> > > > > > > >
> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model
with 9
> > > > > > > > options is too large.
> > > > > > > >
> > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > >
> > > > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #38605 is a reply to message #38439] |
Wed, 10 March 2004 11:32 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------5B936E16B0F12894FB171CDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
If you open a bugzilla defect with your sample schema, I'll look at making changes
in the XSD code to help improve things. One thing I'll try is to change the code
in XSDParticleImpl that tests the size of the <all> to decide if an exact DFA would
be too big:
if (xsdModelGroup.getParticles().size() > 8)
Changing this to perhaps 4 or 5 might help a great deal...
Hayden Marchant wrote:
> I didn't see that version 2.0.0 helped in performance so I'm going ahead
> with a hack to try to speed up the validation since that is the problem
> for <all>. I tried parsing and validating 2 very similar schemas - 1 with
> <all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
> the <sequence> took 1 minute.
>
> I am trying to change the schema temporarily before validation, and then
> change it back. The change that I am making is to change all the model
> groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
> am holding in memory. I have written the code and it is not speeding up
> the validation the same way that a clean schema with <sequence> would. I
> think that my changes are not being propogated through.
>
> I am doing the following:
>
> 1. XSDSchema.setIncrementalUpdate(false);
> 2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
> an ALL_LITERAL
> 3. XSDSchema.update();
> 4. XSDSchema.validate();
> 5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
> that I changed.
> 6. XSDSchema.update().
>
> The validation step at 4. is still taking ages. If I stick in a
> XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
> but I think that I have a step missing to really solve the problem.
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > I don't know about the peformance problem, you'll have to try it and see.
>
> > Hayden Marchant wrote:
>
> > > Does this mean that in Version 2.0, both the performance problem and the
> > > excessive warnings are resolved?
> > >
> > > Thanks,
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In version 2.0 we don't produce this warning anymore because we use an
> > > approximate
> > > > DFA to validate the unique particle attribution rule.
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > > > newer release of Eclipse solves this elegantly, then I can try to
> postpone
> > > > > this issue.
> > > > >
> > > > > Thanks,
> > > > > Hayden
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > Which version of XSD are you using?
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > We're having quite a performance issue with this problem at a
> client
> > > site.
> > > > > > > They have a schema with an <all> with more than 40 particles.
> > > Apparently
> > > > > > > they can go out for lunch while the schema is being parsed.
> > > > > > >
> > > > > > > Can you suggest any workaround for this? I have an ugly idea,
> which is
> > > > > > > pre-processing the schema to change the <all> to a <sequence>. This
> > > would
> > > > > > > be a temporary fix until this issue is resolved. What would be the
> best
> > > > > > > way to do that? I could do this rename through a URIConverter. Do
> you
> > > have
> > > > > > > any other ideas?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Hayden
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > Hayden,
> > > > > > >
> > > > > > > > In order to validate the Unique Particle Attribute rule the XSD
> model
> > > > > builds
> > > > > > > a finite state
> > > > > > > > machine for each content model. Unfortunately a finite state
> machine
> > > > > for an
> > > > > > > <all> content
> > > > > > > > model with n alternatives has n! states. So in cases where the
> > > finite
> > > > > state
> > > > > > > machine is too
> > > > > > > > big to construct I put out a message to that effect. I really
> need
> > > to
> > > > > > > revisit this issue
> > > > > > > > eventually, and handle it more gracefully so you're welcome to
> open a
> > > > > > > bugzilla defect
> > > > > > > > requesting that; I probably won't have time to look at it for
> quite a
> > > > > while.
> > > > > > >
> > > > > > > > Hayden Marchant wrote:
> > > > > > >
> > > > > > > > > I was parsing a pretty simple xsd with the following complex
> type:
> > > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > > <xsd:all>
> > > > > > > > > <xsd:element name="power"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="page"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="mode"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="tag"
> type="xsd:string"/>
> > > > > > > > > <xsd:element name="type"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="devtag"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="sort"
> type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > <xsd:element name="variations"
> > > > > type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > <xsd:element name="locale"
> > > type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > </xsd:all>
> > > > > > > > > </xsd:complexType>
> > > > > > > > >
> > > > > > > > > and I got the following message:
> > > > > > > > >
> > > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model
> with 9
> > > > > > > > > options is too large.
> > > > > > > > >
> > > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > > >
> > > > > > > > > Thanks,
--------------5B936E16B0F12894FB171CDC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>If you open a bugzilla defect with your sample schema, I'll look at
making changes in the XSD code to help improve things. One thing
I'll try is to change the code in XSDParticleImpl that tests the size of
the <all> to decide if an exact DFA would be too big:
<blockquote>if (xsdModelGroup.getParticles().size() > 8)</blockquote>
Changing this to perhaps 4 or 5 might help a great deal...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>I didn't see that version 2.0.0 helped in performance
so I'm going ahead
<br>with a hack to try to speed up the validation since that is the problem
<br>for <all>. I tried parsing and validating 2 very similar schemas
- 1 with
<br><all>s and 1 with <sequence>s and the <all> took more than
20 minutes, and
<br>the <sequence> took 1 minute.
<p>I am trying to change the schema temporarily before validation, and
then
<br>change it back. The change that I am making is to change all the model
<br>groups with the ALL compositor to SEQUENCE on the actual XSDSchema
that I
<br>am holding in memory. I have written the code and it is not speeding
up
<br>the validation the same way that a clean schema with <sequence>
would. I
<br>think that my changes are not being propogated through.
<p>I am doing the following:
<p>1. XSDSchema.setIncrementalUpdate(false);
<br>2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if
it is
<br>an ALL_LITERAL
<br>3. XSDSchema.update();
<br>4. XSDSchema.validate();
<br>5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
<br>that I changed.
<br>6. XSDSchema.update().
<p>The validation step at 4. is still taking ages. If I stick in a
<br>XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
<br>but I think that I have a step missing to really solve the problem.
<p>Thanks,
<p>Ed Merks wrote:
<p>> Hayden,
<p>> I don't know about the peformance problem, you'll have to try it and
see.
<p>> Hayden Marchant wrote:
<p>> > Does this mean that in Version 2.0, both the performance problem
and the
<br>> > excessive warnings are resolved?
<br>> >
<br>> > Thanks,
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > Hayden,
<br>> >
<br>> > > In version 2.0 we don't produce this warning anymore because
we use an
<br>> > approximate
<br>> > > DFA to validate the unique particle attribution rule.
<br>> >
<br>> > > Hayden Marchant wrote:
<br>> >
<br>> > > > I'm currently using 1.1.1. We're are pretty advanced into release
cycle
<br>> > > > and am a bit weary of upgrading eclipse at this stage. Obviously
if a
<br>> > > > newer release of Eclipse solves this elegantly, then I can
try to
<br>postpone
<br>> > > > this issue.
<br>> > > >
<br>> > > > Thanks,
<br>> > > > Hayden
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > Hayden,
<br>> > > >
<br>> > > > > Which version of XSD are you using?
<br>> > > >
<br>> > > > > Hayden Marchant wrote:
<br>> > > >
<br>> > > > > > We're having quite a performance issue with this problem
at a
<br>client
<br>> > site.
<br>> > > > > > They have a schema with an <all> with more than 40 particles.
<br>> > Apparently
<br>> > > > > > they can go out for lunch while the schema is being parsed.
<br>> > > > > >
<br>> > > > > > Can you suggest any workaround for this? I have an ugly
idea,
<br>which is
<br>> > > > > > pre-processing the schema to change the <all> to a <sequence>.
This
<br>> > would
<br>> > > > > > be a temporary fix until this issue is resolved. What would
be the
<br>best
<br>> > > > > > way to do that? I could do this rename through a URIConverter.
Do
<br>you
<br>> > have
<br>> > > > > > any other ideas?
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > > Hayden
<br>> > > > > >
<br>> > > > > > Ed Merks wrote:
<br>> > > > > >
<br>> > > > > > > Hayden,
<br>> > > > > >
<br>> > > > > > > In order to validate the Unique Particle Attribute rule
the XSD
<br>model
<br>> > > > builds
<br>> > > > > > a finite state
<br>> > > > > > > machine for each content model. Unfortunately a
finite state
<br>machine
<br>> > > > for an
<br>> > > > > > <all> content
<br>> > > > > > > model with n alternatives has n! states. So in
cases where the
<br>> > finite
<br>> > > > state
<br>> > > > > > machine is too
<br>> > > > > > > big to construct I put out a message to that effect.
I really
<br>need
<br>> > to
<br>> > > > > > revisit this issue
<br>> > > > > > > eventually, and handle it more gracefully so you're welcome
to
<br>open a
<br>> > > > > > bugzilla defect
<br>> > > > > > > requesting that; I probably won't have time to look at
it for
<br>quite a
<br>> > > > while.
<br>> > > > > >
<br>> > > > > > > Hayden Marchant wrote:
<br>> > > > > >
<br>> > > > > > > > I was parsing a pretty simple xsd with the following
complex
<br>type:
<br>> > > > > > > > <xsd:complexType
name="PowerRequest">
<br>> > > > > > > >
<xsd:all>
<br>> > > > > > > >
<xsd:element name="power"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="page"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="mode"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="tag"
<br>type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="type"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="devtag"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="sort"
<br>type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
<xsd:element name="variations"
<br>> > > > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
<xsd:element name="locale"
<br>> > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
</xsd:all>
<br>> > > > > > > > </xsd:complexType>
<br>> > > > > > > >
<br>> > > > > > > > and I got the following message:
<br>> > > > > > > >
<br>> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content
model
<br>with 9
<br>> > > > > > > > options is too large.
<br>> > > > > > > >
<br>> > > > > > > > Is this according to W3C spec or is it some kind of
bug?
<br>> > > > > > > >
<br>> > > > > > > > Thanks,</blockquote>
</html>
--------------5B936E16B0F12894FB171CDC--
|
|
|
Re: Maximum content for <all> ?? [message #38638 is a reply to message #38605] |
Wed, 10 March 2004 14:49 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I just entered Bugzilla #54289.
Thanks
Ed Merks wrote:
> Hayden,
> If you open a bugzilla defect with your sample schema, I'll look at making
changes
> in the XSD code to help improve things. One thing I'll try is to change the
code
> in XSDParticleImpl that tests the size of the <all> to decide if an exact
DFA would
> be too big:
> if (xsdModelGroup.getParticles().size() > 8)
> Changing this to perhaps 4 or 5 might help a great deal...
> Hayden Marchant wrote:
> > I didn't see that version 2.0.0 helped in performance so I'm going ahead
> > with a hack to try to speed up the validation since that is the problem
> > for <all>. I tried parsing and validating 2 very similar schemas - 1 with
> > <all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
> > the <sequence> took 1 minute.
> >
> > I am trying to change the schema temporarily before validation, and then
> > change it back. The change that I am making is to change all the model
> > groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
> > am holding in memory. I have written the code and it is not speeding up
> > the validation the same way that a clean schema with <sequence> would. I
> > think that my changes are not being propogated through.
> >
> > I am doing the following:
> >
> > 1. XSDSchema.setIncrementalUpdate(false);
> > 2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
> > an ALL_LITERAL
> > 3. XSDSchema.update();
> > 4. XSDSchema.validate();
> > 5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
> > that I changed.
> > 6. XSDSchema.update().
> >
> > The validation step at 4. is still taking ages. If I stick in a
> > XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
> > but I think that I have a step missing to really solve the problem.
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > I don't know about the peformance problem, you'll have to try it and see.
> >
> > > Hayden Marchant wrote:
> >
> > > > Does this mean that in Version 2.0, both the performance problem and
the
> > > > excessive warnings are resolved?
> > > >
> > > > Thanks,
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In version 2.0 we don't produce this warning anymore because we use
an
> > > > approximate
> > > > > DFA to validate the unique particle attribution rule.
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I'm currently using 1.1.1. We're are pretty advanced into release
cycle
> > > > > > and am a bit weary of upgrading eclipse at this stage. Obviously
if a
> > > > > > newer release of Eclipse solves this elegantly, then I can try to
> > postpone
> > > > > > this issue.
> > > > > >
> > > > > > Thanks,
> > > > > > Hayden
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > Which version of XSD are you using?
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > We're having quite a performance issue with this problem at a
> > client
> > > > site.
> > > > > > > > They have a schema with an <all> with more than 40 particles.
> > > > Apparently
> > > > > > > > they can go out for lunch while the schema is being parsed.
> > > > > > > >
> > > > > > > > Can you suggest any workaround for this? I have an ugly idea,
> > which is
> > > > > > > > pre-processing the schema to change the <all> to a <sequence>.
This
> > > > would
> > > > > > > > be a temporary fix until this issue is resolved. What would be
the
> > best
> > > > > > > > way to do that? I could do this rename through a URIConverter.
Do
> > you
> > > > have
> > > > > > > > any other ideas?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Hayden
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > Hayden,
> > > > > > > >
> > > > > > > > > In order to validate the Unique Particle Attribute rule the
XSD
> > model
> > > > > > builds
> > > > > > > > a finite state
> > > > > > > > > machine for each content model. Unfortunately a finite state
> > machine
> > > > > > for an
> > > > > > > > <all> content
> > > > > > > > > model with n alternatives has n! states. So in cases where
the
> > > > finite
> > > > > > state
> > > > > > > > machine is too
> > > > > > > > > big to construct I put out a message to that effect. I
really
> > need
> > > > to
> > > > > > > > revisit this issue
> > > > > > > > > eventually, and handle it more gracefully so you're welcome
to
> > open a
> > > > > > > > bugzilla defect
> > > > > > > > > requesting that; I probably won't have time to look at it for
> > quite a
> > > > > > while.
> > > > > > > >
> > > > > > > > > Hayden Marchant wrote:
> > > > > > > >
> > > > > > > > > > I was parsing a pretty simple xsd with the following
complex
> > type:
> > > > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > > > <xsd:all>
> > > > > > > > > > <xsd:element name="power"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="page"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="mode"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="tag"
> > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="type"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="devtag"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="sort"
> > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > <xsd:element name="variations"
> > > > > > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > <xsd:element name="locale"
> > > > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > </xsd:all>
> > > > > > > > > > </xsd:complexType>
> > > > > > > > > >
> > > > > > > > > > and I got the following message:
> > > > > > > > > >
> > > > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content
model
> > with 9
> > > > > > > > > > options is too large.
> > > > > > > > > >
> > > > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #580645 is a reply to message #32831] |
Mon, 10 November 2003 11:54 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Hayden,
In order to validate the Unique Particle Attribute rule the XSD model builds a finite state
machine for each content model. Unfortunately a finite state machine for an <all> content
model with n alternatives has n! states. So in cases where the finite state machine is too
big to construct I put out a message to that effect. I really need to revisit this issue
eventually, and handle it more gracefully so you're welcome to open a bugzilla defect
requesting that; I probably won't have time to look at it for quite a while.
Hayden Marchant wrote:
> I was parsing a pretty simple xsd with the following complex type:
> <xsd:complexType name="PowerRequest">
> <xsd:all>
> <xsd:element name="power" type="xsd:string"/>
> <xsd:element name="page" type="xsd:string"/>
> <xsd:element name="mode" type="xsd:string"/>
> <xsd:element name="tag" type="xsd:string"/>
> <xsd:element name="type" type="xsd:string"/>
> <xsd:element name="devtag" type="xsd:string"/>
> <xsd:element name="sort" type="xsd:string" minOccurs="0"/>
> <xsd:element name="variations" type="xsd:string" minOccurs="0"/>
> <xsd:element name="locale" type="xsd:string" minOccurs="0"/>
> </xsd:all>
> </xsd:complexType>
>
> and I got the following message:
>
> Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> options is too large.
>
> Is this according to W3C spec or is it some kind of bug?
>
> Thanks,
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: Maximum content for <all> ?? [message #583750 is a reply to message #37816] |
Thu, 04 March 2004 16:46 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Hayden,
Which version of XSD are you using?
Hayden Marchant wrote:
> We're having quite a performance issue with this problem at a client site.
> They have a schema with an <all> with more than 40 particles. Apparently
> they can go out for lunch while the schema is being parsed.
>
> Can you suggest any workaround for this? I have an ugly idea, which is
> pre-processing the schema to change the <all> to a <sequence>. This would
> be a temporary fix until this issue is resolved. What would be the best
> way to do that? I could do this rename through a URIConverter. Do you have
> any other ideas?
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In order to validate the Unique Particle Attribute rule the XSD model builds
> a finite state
> > machine for each content model. Unfortunately a finite state machine for an
> <all> content
> > model with n alternatives has n! states. So in cases where the finite state
> machine is too
> > big to construct I put out a message to that effect. I really need to
> revisit this issue
> > eventually, and handle it more gracefully so you're welcome to open a
> bugzilla defect
> > requesting that; I probably won't have time to look at it for quite a while.
>
> > Hayden Marchant wrote:
>
> > > I was parsing a pretty simple xsd with the following complex type:
> > > <xsd:complexType name="PowerRequest">
> > > <xsd:all>
> > > <xsd:element name="power" type="xsd:string"/>
> > > <xsd:element name="page" type="xsd:string"/>
> > > <xsd:element name="mode" type="xsd:string"/>
> > > <xsd:element name="tag" type="xsd:string"/>
> > > <xsd:element name="type" type="xsd:string"/>
> > > <xsd:element name="devtag" type="xsd:string"/>
> > > <xsd:element name="sort" type="xsd:string"
> minOccurs="0"/>
> > > <xsd:element name="variations" type="xsd:string"
> minOccurs="0"/>
> > > <xsd:element name="locale" type="xsd:string"
> minOccurs="0"/>
> > > </xsd:all>
> > > </xsd:complexType>
> > >
> > > and I got the following message:
> > >
> > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > options is too large.
> > >
> > > Is this according to W3C spec or is it some kind of bug?
> > >
> > > Thanks,
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: Maximum content for <all> ?? [message #583833 is a reply to message #37995] |
Mon, 08 March 2004 11:52 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Hayden,
In version 2.0 we don't produce this warning anymore because we use an approximate
DFA to validate the unique particle attribution rule.
Hayden Marchant wrote:
> I'm currently using 1.1.1. We're are pretty advanced into release cycle
> and am a bit weary of upgrading eclipse at this stage. Obviously if a
> newer release of Eclipse solves this elegantly, then I can try to postpone
> this issue.
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Which version of XSD are you using?
>
> > Hayden Marchant wrote:
>
> > > We're having quite a performance issue with this problem at a client site.
> > > They have a schema with an <all> with more than 40 particles. Apparently
> > > they can go out for lunch while the schema is being parsed.
> > >
> > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > pre-processing the schema to change the <all> to a <sequence>. This would
> > > be a temporary fix until this issue is resolved. What would be the best
> > > way to do that? I could do this rename through a URIConverter. Do you have
> > > any other ideas?
> > >
> > > Thanks,
> > > Hayden
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In order to validate the Unique Particle Attribute rule the XSD model
> builds
> > > a finite state
> > > > machine for each content model. Unfortunately a finite state machine
> for an
> > > <all> content
> > > > model with n alternatives has n! states. So in cases where the finite
> state
> > > machine is too
> > > > big to construct I put out a message to that effect. I really need to
> > > revisit this issue
> > > > eventually, and handle it more gracefully so you're welcome to open a
> > > bugzilla defect
> > > > requesting that; I probably won't have time to look at it for quite a
> while.
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > <xsd:complexType name="PowerRequest">
> > > > > <xsd:all>
> > > > > <xsd:element name="power" type="xsd:string"/>
> > > > > <xsd:element name="page" type="xsd:string"/>
> > > > > <xsd:element name="mode" type="xsd:string"/>
> > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > <xsd:element name="type" type="xsd:string"/>
> > > > > <xsd:element name="devtag" type="xsd:string"/>
> > > > > <xsd:element name="sort" type="xsd:string"
> > > minOccurs="0"/>
> > > > > <xsd:element name="variations"
> type="xsd:string"
> > > minOccurs="0"/>
> > > > > <xsd:element name="locale" type="xsd:string"
> > > minOccurs="0"/>
> > > > > </xsd:all>
> > > > > </xsd:complexType>
> > > > >
> > > > > and I got the following message:
> > > > >
> > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > options is too large.
> > > > >
> > > > > Is this according to W3C spec or is it some kind of bug?
> > > > >
> > > > > Thanks,
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Maximum content for <all> ?? [message #583917 is a reply to message #38046] |
Mon, 08 March 2004 15:44 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
Does this mean that in Version 2.0, both the performance problem and the
excessive warnings are resolved?
Thanks,
Ed Merks wrote:
> Hayden,
> In version 2.0 we don't produce this warning anymore because we use an
approximate
> DFA to validate the unique particle attribution rule.
> Hayden Marchant wrote:
> > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > newer release of Eclipse solves this elegantly, then I can try to postpone
> > this issue.
> >
> > Thanks,
> > Hayden
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Which version of XSD are you using?
> >
> > > Hayden Marchant wrote:
> >
> > > > We're having quite a performance issue with this problem at a client
site.
> > > > They have a schema with an <all> with more than 40 particles.
Apparently
> > > > they can go out for lunch while the schema is being parsed.
> > > >
> > > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > > pre-processing the schema to change the <all> to a <sequence>. This
would
> > > > be a temporary fix until this issue is resolved. What would be the best
> > > > way to do that? I could do this rename through a URIConverter. Do you
have
> > > > any other ideas?
> > > >
> > > > Thanks,
> > > > Hayden
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In order to validate the Unique Particle Attribute rule the XSD model
> > builds
> > > > a finite state
> > > > > machine for each content model. Unfortunately a finite state machine
> > for an
> > > > <all> content
> > > > > model with n alternatives has n! states. So in cases where the
finite
> > state
> > > > machine is too
> > > > > big to construct I put out a message to that effect. I really need
to
> > > > revisit this issue
> > > > > eventually, and handle it more gracefully so you're welcome to open a
> > > > bugzilla defect
> > > > > requesting that; I probably won't have time to look at it for quite a
> > while.
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > > <xsd:complexType name="PowerRequest">
> > > > > > <xsd:all>
> > > > > > <xsd:element name="power"
type="xsd:string"/>
> > > > > > <xsd:element name="page"
type="xsd:string"/>
> > > > > > <xsd:element name="mode"
type="xsd:string"/>
> > > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > > <xsd:element name="type"
type="xsd:string"/>
> > > > > > <xsd:element name="devtag"
type="xsd:string"/>
> > > > > > <xsd:element name="sort" type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > <xsd:element name="variations"
> > type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > <xsd:element name="locale"
type="xsd:string"
> > > > minOccurs="0"/>
> > > > > > </xsd:all>
> > > > > > </xsd:complexType>
> > > > > >
> > > > > > and I got the following message:
> > > > > >
> > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > > options is too large.
> > > > > >
> > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > >
> > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #583975 is a reply to message #38239] |
Mon, 08 March 2004 16:32 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Hayden,
I don't know about the peformance problem, you'll have to try it and see.
Hayden Marchant wrote:
> Does this mean that in Version 2.0, both the performance problem and the
> excessive warnings are resolved?
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In version 2.0 we don't produce this warning anymore because we use an
> approximate
> > DFA to validate the unique particle attribution rule.
>
> > Hayden Marchant wrote:
>
> > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > newer release of Eclipse solves this elegantly, then I can try to postpone
> > > this issue.
> > >
> > > Thanks,
> > > Hayden
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > Which version of XSD are you using?
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > We're having quite a performance issue with this problem at a client
> site.
> > > > > They have a schema with an <all> with more than 40 particles.
> Apparently
> > > > > they can go out for lunch while the schema is being parsed.
> > > > >
> > > > > Can you suggest any workaround for this? I have an ugly idea, which is
> > > > > pre-processing the schema to change the <all> to a <sequence>. This
> would
> > > > > be a temporary fix until this issue is resolved. What would be the best
> > > > > way to do that? I could do this rename through a URIConverter. Do you
> have
> > > > > any other ideas?
> > > > >
> > > > > Thanks,
> > > > > Hayden
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > In order to validate the Unique Particle Attribute rule the XSD model
> > > builds
> > > > > a finite state
> > > > > > machine for each content model. Unfortunately a finite state machine
> > > for an
> > > > > <all> content
> > > > > > model with n alternatives has n! states. So in cases where the
> finite
> > > state
> > > > > machine is too
> > > > > > big to construct I put out a message to that effect. I really need
> to
> > > > > revisit this issue
> > > > > > eventually, and handle it more gracefully so you're welcome to open a
> > > > > bugzilla defect
> > > > > > requesting that; I probably won't have time to look at it for quite a
> > > while.
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > I was parsing a pretty simple xsd with the following complex type:
> > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > <xsd:all>
> > > > > > > <xsd:element name="power"
> type="xsd:string"/>
> > > > > > > <xsd:element name="page"
> type="xsd:string"/>
> > > > > > > <xsd:element name="mode"
> type="xsd:string"/>
> > > > > > > <xsd:element name="tag" type="xsd:string"/>
> > > > > > > <xsd:element name="type"
> type="xsd:string"/>
> > > > > > > <xsd:element name="devtag"
> type="xsd:string"/>
> > > > > > > <xsd:element name="sort" type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > <xsd:element name="variations"
> > > type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > <xsd:element name="locale"
> type="xsd:string"
> > > > > minOccurs="0"/>
> > > > > > > </xsd:all>
> > > > > > > </xsd:complexType>
> > > > > > >
> > > > > > > and I got the following message:
> > > > > > >
> > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model with 9
> > > > > > > options is too large.
> > > > > > >
> > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > >
> > > > > > > Thanks,
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Maximum content for <all> ?? [message #584012 is a reply to message #38338] |
Tue, 09 March 2004 08:41 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I didn't see that version 2.0.0 helped in performance so I'm going ahead
with a hack to try to speed up the validation since that is the problem
for <all>. I tried parsing and validating 2 very similar schemas - 1 with
<all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
the <sequence> took 1 minute.
I am trying to change the schema temporarily before validation, and then
change it back. The change that I am making is to change all the model
groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
am holding in memory. I have written the code and it is not speeding up
the validation the same way that a clean schema with <sequence> would. I
think that my changes are not being propogated through.
I am doing the following:
1. XSDSchema.setIncrementalUpdate(false);
2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
an ALL_LITERAL
3. XSDSchema.update();
4. XSDSchema.validate();
5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
that I changed.
6. XSDSchema.update().
The validation step at 4. is still taking ages. If I stick in a
XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
but I think that I have a step missing to really solve the problem.
Thanks,
Ed Merks wrote:
> Hayden,
> I don't know about the peformance problem, you'll have to try it and see.
> Hayden Marchant wrote:
> > Does this mean that in Version 2.0, both the performance problem and the
> > excessive warnings are resolved?
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > In version 2.0 we don't produce this warning anymore because we use an
> > approximate
> > > DFA to validate the unique particle attribution rule.
> >
> > > Hayden Marchant wrote:
> >
> > > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > > newer release of Eclipse solves this elegantly, then I can try to
postpone
> > > > this issue.
> > > >
> > > > Thanks,
> > > > Hayden
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > Which version of XSD are you using?
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > We're having quite a performance issue with this problem at a
client
> > site.
> > > > > > They have a schema with an <all> with more than 40 particles.
> > Apparently
> > > > > > they can go out for lunch while the schema is being parsed.
> > > > > >
> > > > > > Can you suggest any workaround for this? I have an ugly idea,
which is
> > > > > > pre-processing the schema to change the <all> to a <sequence>. This
> > would
> > > > > > be a temporary fix until this issue is resolved. What would be the
best
> > > > > > way to do that? I could do this rename through a URIConverter. Do
you
> > have
> > > > > > any other ideas?
> > > > > >
> > > > > > Thanks,
> > > > > > Hayden
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > In order to validate the Unique Particle Attribute rule the XSD
model
> > > > builds
> > > > > > a finite state
> > > > > > > machine for each content model. Unfortunately a finite state
machine
> > > > for an
> > > > > > <all> content
> > > > > > > model with n alternatives has n! states. So in cases where the
> > finite
> > > > state
> > > > > > machine is too
> > > > > > > big to construct I put out a message to that effect. I really
need
> > to
> > > > > > revisit this issue
> > > > > > > eventually, and handle it more gracefully so you're welcome to
open a
> > > > > > bugzilla defect
> > > > > > > requesting that; I probably won't have time to look at it for
quite a
> > > > while.
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > I was parsing a pretty simple xsd with the following complex
type:
> > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > <xsd:all>
> > > > > > > > <xsd:element name="power"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="page"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="mode"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="tag"
type="xsd:string"/>
> > > > > > > > <xsd:element name="type"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="devtag"
> > type="xsd:string"/>
> > > > > > > > <xsd:element name="sort"
type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > <xsd:element name="variations"
> > > > type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > <xsd:element name="locale"
> > type="xsd:string"
> > > > > > minOccurs="0"/>
> > > > > > > > </xsd:all>
> > > > > > > > </xsd:complexType>
> > > > > > > >
> > > > > > > > and I got the following message:
> > > > > > > >
> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model
with 9
> > > > > > > > options is too large.
> > > > > > > >
> > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > >
> > > > > > > > Thanks,
|
|
|
Re: Maximum content for <all> ?? [message #584088 is a reply to message #38439] |
Wed, 10 March 2004 11:32 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
--------------5B936E16B0F12894FB171CDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
If you open a bugzilla defect with your sample schema, I'll look at making changes
in the XSD code to help improve things. One thing I'll try is to change the code
in XSDParticleImpl that tests the size of the <all> to decide if an exact DFA would
be too big:
if (xsdModelGroup.getParticles().size() > 8)
Changing this to perhaps 4 or 5 might help a great deal...
Hayden Marchant wrote:
> I didn't see that version 2.0.0 helped in performance so I'm going ahead
> with a hack to try to speed up the validation since that is the problem
> for <all>. I tried parsing and validating 2 very similar schemas - 1 with
> <all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
> the <sequence> took 1 minute.
>
> I am trying to change the schema temporarily before validation, and then
> change it back. The change that I am making is to change all the model
> groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
> am holding in memory. I have written the code and it is not speeding up
> the validation the same way that a clean schema with <sequence> would. I
> think that my changes are not being propogated through.
>
> I am doing the following:
>
> 1. XSDSchema.setIncrementalUpdate(false);
> 2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
> an ALL_LITERAL
> 3. XSDSchema.update();
> 4. XSDSchema.validate();
> 5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
> that I changed.
> 6. XSDSchema.update().
>
> The validation step at 4. is still taking ages. If I stick in a
> XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
> but I think that I have a step missing to really solve the problem.
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > I don't know about the peformance problem, you'll have to try it and see.
>
> > Hayden Marchant wrote:
>
> > > Does this mean that in Version 2.0, both the performance problem and the
> > > excessive warnings are resolved?
> > >
> > > Thanks,
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In version 2.0 we don't produce this warning anymore because we use an
> > > approximate
> > > > DFA to validate the unique particle attribution rule.
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I'm currently using 1.1.1. We're are pretty advanced into release cycle
> > > > > and am a bit weary of upgrading eclipse at this stage. Obviously if a
> > > > > newer release of Eclipse solves this elegantly, then I can try to
> postpone
> > > > > this issue.
> > > > >
> > > > > Thanks,
> > > > > Hayden
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > Which version of XSD are you using?
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > We're having quite a performance issue with this problem at a
> client
> > > site.
> > > > > > > They have a schema with an <all> with more than 40 particles.
> > > Apparently
> > > > > > > they can go out for lunch while the schema is being parsed.
> > > > > > >
> > > > > > > Can you suggest any workaround for this? I have an ugly idea,
> which is
> > > > > > > pre-processing the schema to change the <all> to a <sequence>. This
> > > would
> > > > > > > be a temporary fix until this issue is resolved. What would be the
> best
> > > > > > > way to do that? I could do this rename through a URIConverter. Do
> you
> > > have
> > > > > > > any other ideas?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Hayden
> > > > > > >
> > > > > > > Ed Merks wrote:
> > > > > > >
> > > > > > > > Hayden,
> > > > > > >
> > > > > > > > In order to validate the Unique Particle Attribute rule the XSD
> model
> > > > > builds
> > > > > > > a finite state
> > > > > > > > machine for each content model. Unfortunately a finite state
> machine
> > > > > for an
> > > > > > > <all> content
> > > > > > > > model with n alternatives has n! states. So in cases where the
> > > finite
> > > > > state
> > > > > > > machine is too
> > > > > > > > big to construct I put out a message to that effect. I really
> need
> > > to
> > > > > > > revisit this issue
> > > > > > > > eventually, and handle it more gracefully so you're welcome to
> open a
> > > > > > > bugzilla defect
> > > > > > > > requesting that; I probably won't have time to look at it for
> quite a
> > > > > while.
> > > > > > >
> > > > > > > > Hayden Marchant wrote:
> > > > > > >
> > > > > > > > > I was parsing a pretty simple xsd with the following complex
> type:
> > > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > > <xsd:all>
> > > > > > > > > <xsd:element name="power"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="page"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="mode"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="tag"
> type="xsd:string"/>
> > > > > > > > > <xsd:element name="type"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="devtag"
> > > type="xsd:string"/>
> > > > > > > > > <xsd:element name="sort"
> type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > <xsd:element name="variations"
> > > > > type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > <xsd:element name="locale"
> > > type="xsd:string"
> > > > > > > minOccurs="0"/>
> > > > > > > > > </xsd:all>
> > > > > > > > > </xsd:complexType>
> > > > > > > > >
> > > > > > > > > and I got the following message:
> > > > > > > > >
> > > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content model
> with 9
> > > > > > > > > options is too large.
> > > > > > > > >
> > > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > > >
> > > > > > > > > Thanks,
--------------5B936E16B0F12894FB171CDC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>If you open a bugzilla defect with your sample schema, I'll look at
making changes in the XSD code to help improve things. One thing
I'll try is to change the code in XSDParticleImpl that tests the size of
the <all> to decide if an exact DFA would be too big:
<blockquote>if (xsdModelGroup.getParticles().size() > 8)</blockquote>
Changing this to perhaps 4 or 5 might help a great deal...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>I didn't see that version 2.0.0 helped in performance
so I'm going ahead
<br>with a hack to try to speed up the validation since that is the problem
<br>for <all>. I tried parsing and validating 2 very similar schemas
- 1 with
<br><all>s and 1 with <sequence>s and the <all> took more than
20 minutes, and
<br>the <sequence> took 1 minute.
<p>I am trying to change the schema temporarily before validation, and
then
<br>change it back. The change that I am making is to change all the model
<br>groups with the ALL compositor to SEQUENCE on the actual XSDSchema
that I
<br>am holding in memory. I have written the code and it is not speeding
up
<br>the validation the same way that a clean schema with <sequence>
would. I
<br>think that my changes are not being propogated through.
<p>I am doing the following:
<p>1. XSDSchema.setIncrementalUpdate(false);
<br>2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if
it is
<br>an ALL_LITERAL
<br>3. XSDSchema.update();
<br>4. XSDSchema.validate();
<br>5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
<br>that I changed.
<br>6. XSDSchema.update().
<p>The validation step at 4. is still taking ages. If I stick in a
<br>XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
<br>but I think that I have a step missing to really solve the problem.
<p>Thanks,
<p>Ed Merks wrote:
<p>> Hayden,
<p>> I don't know about the peformance problem, you'll have to try it and
see.
<p>> Hayden Marchant wrote:
<p>> > Does this mean that in Version 2.0, both the performance problem
and the
<br>> > excessive warnings are resolved?
<br>> >
<br>> > Thanks,
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > Hayden,
<br>> >
<br>> > > In version 2.0 we don't produce this warning anymore because
we use an
<br>> > approximate
<br>> > > DFA to validate the unique particle attribution rule.
<br>> >
<br>> > > Hayden Marchant wrote:
<br>> >
<br>> > > > I'm currently using 1.1.1. We're are pretty advanced into release
cycle
<br>> > > > and am a bit weary of upgrading eclipse at this stage. Obviously
if a
<br>> > > > newer release of Eclipse solves this elegantly, then I can
try to
<br>postpone
<br>> > > > this issue.
<br>> > > >
<br>> > > > Thanks,
<br>> > > > Hayden
<br>> > > >
<br>> > > > Ed Merks wrote:
<br>> > > >
<br>> > > > > Hayden,
<br>> > > >
<br>> > > > > Which version of XSD are you using?
<br>> > > >
<br>> > > > > Hayden Marchant wrote:
<br>> > > >
<br>> > > > > > We're having quite a performance issue with this problem
at a
<br>client
<br>> > site.
<br>> > > > > > They have a schema with an <all> with more than 40 particles.
<br>> > Apparently
<br>> > > > > > they can go out for lunch while the schema is being parsed.
<br>> > > > > >
<br>> > > > > > Can you suggest any workaround for this? I have an ugly
idea,
<br>which is
<br>> > > > > > pre-processing the schema to change the <all> to a <sequence>.
This
<br>> > would
<br>> > > > > > be a temporary fix until this issue is resolved. What would
be the
<br>best
<br>> > > > > > way to do that? I could do this rename through a URIConverter.
Do
<br>you
<br>> > have
<br>> > > > > > any other ideas?
<br>> > > > > >
<br>> > > > > > Thanks,
<br>> > > > > > Hayden
<br>> > > > > >
<br>> > > > > > Ed Merks wrote:
<br>> > > > > >
<br>> > > > > > > Hayden,
<br>> > > > > >
<br>> > > > > > > In order to validate the Unique Particle Attribute rule
the XSD
<br>model
<br>> > > > builds
<br>> > > > > > a finite state
<br>> > > > > > > machine for each content model. Unfortunately a
finite state
<br>machine
<br>> > > > for an
<br>> > > > > > <all> content
<br>> > > > > > > model with n alternatives has n! states. So in
cases where the
<br>> > finite
<br>> > > > state
<br>> > > > > > machine is too
<br>> > > > > > > big to construct I put out a message to that effect.
I really
<br>need
<br>> > to
<br>> > > > > > revisit this issue
<br>> > > > > > > eventually, and handle it more gracefully so you're welcome
to
<br>open a
<br>> > > > > > bugzilla defect
<br>> > > > > > > requesting that; I probably won't have time to look at
it for
<br>quite a
<br>> > > > while.
<br>> > > > > >
<br>> > > > > > > Hayden Marchant wrote:
<br>> > > > > >
<br>> > > > > > > > I was parsing a pretty simple xsd with the following
complex
<br>type:
<br>> > > > > > > > <xsd:complexType
name="PowerRequest">
<br>> > > > > > > >
<xsd:all>
<br>> > > > > > > >
<xsd:element name="power"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="page"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="mode"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="tag"
<br>type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="type"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="devtag"
<br>> > type="xsd:string"/>
<br>> > > > > > > >
<xsd:element name="sort"
<br>type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
<xsd:element name="variations"
<br>> > > > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
<xsd:element name="locale"
<br>> > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > >
</xsd:all>
<br>> > > > > > > > </xsd:complexType>
<br>> > > > > > > >
<br>> > > > > > > > and I got the following message:
<br>> > > > > > > >
<br>> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content
model
<br>with 9
<br>> > > > > > > > options is too large.
<br>> > > > > > > >
<br>> > > > > > > > Is this according to W3C spec or is it some kind of
bug?
<br>> > > > > > > >
<br>> > > > > > > > Thanks,</blockquote>
</html>
--------------5B936E16B0F12894FB171CDC--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Maximum content for <all> ?? [message #584099 is a reply to message #38605] |
Wed, 10 March 2004 14:49 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I just entered Bugzilla #54289.
Thanks
Ed Merks wrote:
> Hayden,
> If you open a bugzilla defect with your sample schema, I'll look at making
changes
> in the XSD code to help improve things. One thing I'll try is to change the
code
> in XSDParticleImpl that tests the size of the <all> to decide if an exact
DFA would
> be too big:
> if (xsdModelGroup.getParticles().size() > 8)
> Changing this to perhaps 4 or 5 might help a great deal...
> Hayden Marchant wrote:
> > I didn't see that version 2.0.0 helped in performance so I'm going ahead
> > with a hack to try to speed up the validation since that is the problem
> > for <all>. I tried parsing and validating 2 very similar schemas - 1 with
> > <all>s and 1 with <sequence>s and the <all> took more than 20 minutes, and
> > the <sequence> took 1 minute.
> >
> > I am trying to change the schema temporarily before validation, and then
> > change it back. The change that I am making is to change all the model
> > groups with the ALL compositor to SEQUENCE on the actual XSDSchema that I
> > am holding in memory. I have written the code and it is not speeding up
> > the validation the same way that a clean schema with <sequence> would. I
> > think that my changes are not being propogated through.
> >
> > I am doing the following:
> >
> > 1. XSDSchema.setIncrementalUpdate(false);
> > 2. XSDModelGroup.setCompositor(XSDComposite.SEQUENCE_LITERAL) - if it is
> > an ALL_LITERAL
> > 3. XSDSchema.update();
> > 4. XSDSchema.validate();
> > 5. XSDModelGroup.seCompositor(XSDComposite.ALL_LITERAL) - for all those
> > that I changed.
> > 6. XSDSchema.update().
> >
> > The validation step at 4. is still taking ages. If I stick in a
> > XSDSchema.eResource().save(..), in between 3. and 4. I do see my changes,
> > but I think that I have a step missing to really solve the problem.
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > I don't know about the peformance problem, you'll have to try it and see.
> >
> > > Hayden Marchant wrote:
> >
> > > > Does this mean that in Version 2.0, both the performance problem and
the
> > > > excessive warnings are resolved?
> > > >
> > > > Thanks,
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In version 2.0 we don't produce this warning anymore because we use
an
> > > > approximate
> > > > > DFA to validate the unique particle attribution rule.
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I'm currently using 1.1.1. We're are pretty advanced into release
cycle
> > > > > > and am a bit weary of upgrading eclipse at this stage. Obviously
if a
> > > > > > newer release of Eclipse solves this elegantly, then I can try to
> > postpone
> > > > > > this issue.
> > > > > >
> > > > > > Thanks,
> > > > > > Hayden
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > Which version of XSD are you using?
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > We're having quite a performance issue with this problem at a
> > client
> > > > site.
> > > > > > > > They have a schema with an <all> with more than 40 particles.
> > > > Apparently
> > > > > > > > they can go out for lunch while the schema is being parsed.
> > > > > > > >
> > > > > > > > Can you suggest any workaround for this? I have an ugly idea,
> > which is
> > > > > > > > pre-processing the schema to change the <all> to a <sequence>.
This
> > > > would
> > > > > > > > be a temporary fix until this issue is resolved. What would be
the
> > best
> > > > > > > > way to do that? I could do this rename through a URIConverter.
Do
> > you
> > > > have
> > > > > > > > any other ideas?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Hayden
> > > > > > > >
> > > > > > > > Ed Merks wrote:
> > > > > > > >
> > > > > > > > > Hayden,
> > > > > > > >
> > > > > > > > > In order to validate the Unique Particle Attribute rule the
XSD
> > model
> > > > > > builds
> > > > > > > > a finite state
> > > > > > > > > machine for each content model. Unfortunately a finite state
> > machine
> > > > > > for an
> > > > > > > > <all> content
> > > > > > > > > model with n alternatives has n! states. So in cases where
the
> > > > finite
> > > > > > state
> > > > > > > > machine is too
> > > > > > > > > big to construct I put out a message to that effect. I
really
> > need
> > > > to
> > > > > > > > revisit this issue
> > > > > > > > > eventually, and handle it more gracefully so you're welcome
to
> > open a
> > > > > > > > bugzilla defect
> > > > > > > > > requesting that; I probably won't have time to look at it for
> > quite a
> > > > > > while.
> > > > > > > >
> > > > > > > > > Hayden Marchant wrote:
> > > > > > > >
> > > > > > > > > > I was parsing a pretty simple xsd with the following
complex
> > type:
> > > > > > > > > > <xsd:complexType name="PowerRequest">
> > > > > > > > > > <xsd:all>
> > > > > > > > > > <xsd:element name="power"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="page"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="mode"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="tag"
> > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="type"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="devtag"
> > > > type="xsd:string"/>
> > > > > > > > > > <xsd:element name="sort"
> > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > <xsd:element name="variations"
> > > > > > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > <xsd:element name="locale"
> > > > type="xsd:string"
> > > > > > > > minOccurs="0"/>
> > > > > > > > > > </xsd:all>
> > > > > > > > > > </xsd:complexType>
> > > > > > > > > >
> > > > > > > > > > and I got the following message:
> > > > > > > > > >
> > > > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The <all> content
model
> > with 9
> > > > > > > > > > options is too large.
> > > > > > > > > >
> > > > > > > > > > Is this according to W3C spec or is it some kind of bug?
> > > > > > > > > >
> > > > > > > > > > Thanks,
|
|
|
Goto Forum:
Current Time: Thu Sep 26 11:57:38 GMT 2024
Powered by FUDForum. Page generated in 0.06792 seconds
|