Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » XML Schema Definition (XSD) » Maximum content for <all> ??
Maximum content for <all> ?? [message #32831] Sun, 09 November 2003 17:48 Go to next message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #32903 is a reply to message #32831] Mon, 10 November 2003 11:54 Go to previous messageGo to next message
Eclipse UserFriend
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 #37816 is a reply to message #32903] Thu, 04 March 2004 15:07 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #37915 is a reply to message #37816] Thu, 04 March 2004 16:46 Go to previous messageGo to next message
Eclipse UserFriend
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 #37995 is a reply to message #37915] Mon, 08 March 2004 07:19 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #38046 is a reply to message #37995] Mon, 08 March 2004 11:52 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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.&nbsp; One thing
I'll try is to change the code in XSDParticleImpl that tests the size of
the &lt;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>&nbsp;
<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 &lt;all>. I tried parsing and validating 2 very similar schemas
- 1 with
<br>&lt;all>s and 1 with &lt;sequence>s and the &lt;all> took more than
20 minutes, and
<br>the &lt;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 &lt;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 &lt;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 &lt;all> to a &lt;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.&nbsp; Unfortunately a
finite state
<br>machine
<br>> > > > for an
<br>> > > > > > &lt;all> content
<br>> > > > > > > model with n alternatives has n! states.&nbsp; 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.&nbsp;
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>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;xsd:complexType
name="PowerRequest">
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:all>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="power"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="page"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="mode"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="tag"
<br>type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="type"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="devtag"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="sort"
<br>type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="variations"
<br>> > > > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="locale"
<br>> > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xsd:all>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;/xsd:complexType>
<br>> > > > > > > >
<br>> > > > > > > > and I got the following message:
<br>> > > > > > > >
<br>> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The &lt;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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 #583699 is a reply to message #32903] Thu, 04 March 2004 15:07 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #583750 is a reply to message #37816] Thu, 04 March 2004 16:46 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 #583805 is a reply to message #37915] Mon, 08 March 2004 07:19 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #583833 is a reply to message #37995] Mon, 08 March 2004 11:52 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
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.&nbsp; One thing
I'll try is to change the code in XSDParticleImpl that tests the size of
the &lt;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>&nbsp;
<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 &lt;all>. I tried parsing and validating 2 very similar schemas
- 1 with
<br>&lt;all>s and 1 with &lt;sequence>s and the &lt;all> took more than
20 minutes, and
<br>the &lt;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 &lt;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 &lt;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 &lt;all> to a &lt;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.&nbsp; Unfortunately a
finite state
<br>machine
<br>> > > > for an
<br>> > > > > > &lt;all> content
<br>> > > > > > > model with n alternatives has n! states.&nbsp; 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.&nbsp;
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>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;xsd:complexType
name="PowerRequest">
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:all>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="power"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="page"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="mode"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="tag"
<br>type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="type"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="devtag"
<br>> > type="xsd:string"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="sort"
<br>type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="variations"
<br>> > > > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;xsd:element name="locale"
<br>> > type="xsd:string"
<br>> > > > > > minOccurs="0"/>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
&lt;/xsd:all>
<br>> > > > > > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &lt;/xsd:complexType>
<br>> > > > > > > >
<br>> > > > > > > > and I got the following message:
<br>> > > > > > > >
<br>> > > > > > > > Line 60 : bookNs#PowerRequest : XSD: The &lt;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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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,
Previous Topic:Problem with XSD 2.0.0 with Regex Patterns
Next Topic:Announcement: EMF and XSD CVS Repositories - Opinions Requested
Goto Forum:
  


Current Time: Fri Mar 29 01:52:52 GMT 2024

Powered by FUDForum. Page generated in 0.04483 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top