[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [Summary] Constrain the Number of Occurrences of Elements in

• To: "'XML Developers List'" <xml-dev@l...>
• Subject: Re: [Summary] Constrain the Number of Occurrences of Elements in
• Subject: Re: [Summary] Constrain the Number of Occurrences of Elements in your XML Schema
• From: "Rick Jelliffe" <ricko@a...>
• Date: Tue, 9 Aug 2005 19:04:58 +1000 (EST)
• Importance: Normal
• In-reply-to: <200508081157.j78BvfS15116@s...>
• References: <D45A5694803BE943BA46F9A7262BF83D01A14964@i...> <200508081157.j78BvfS15116@s...>
• User-agent: SquirrelMail/1.4.2

The root problem is using grammars in the first place. Moving from FSM
to derivitatives is nice, but the validation-by-parsing model is just a
bad fit for XML. It made sense in SGML, where you needed a grammar to
parse symbols such as short-refs, but it is a carbuncle on XML.
It needs to be replaced by a path based system that allows random access
validation, where types can be statically replaced by paths.

It makes little sense to me that one system (grammars) is required to
validate and assign type, then another (paths) to transform. It is
double handling, inefficient and complex for humans.

So I think a much better approach than either smarter FSM or
derivatives would be to compile grammars into path-based rule
implementations (whether this is XPaths or something with better formal
termination characteristics and easier logic or optimisability
is a different matter). Why require a validation stage when Bookstore/Book
is enough to identify an element with a particular type?

> Issue
>
>
> Should unbounded occurrences be permitted in an XML Schema?

I think "Should" needs to be clarified: is it "should" because
of pragmatic reasons (performance, algorithms, etc) or because
of theoretical reasons (which layer?: "data model", "security",
"tuning", "application",etc.)

And I would rephrase the question as "Should large bounded
occurrences be permitted in an XML Schema"?  Mere unboundedness
doesn't seem to have problems.

It seems that medium to large bounded occurrences (perhaps as
low as a hundred?) should be avoided whereever possible, except
for schemas intended for particular implementations which are
known to use or be safe with large bounded occurrences (e.g.
for some application generator.)

Schematron is practical for filling in many of the gaps between
capabilities of tools/schemas and theoretical layers.

Cheers
Rick Jelliffe

P.S. The annotation containing the assertions should belong
to the Bookstore element declaration not the local Book element
declaration.

 <schematron:assert test="count(Book) <= 30000"/>

• References:
  • Re: Constrain the Number of Occurrences of Elements in your XML Schema
    • From: James Lindley Walford <jlw@i...>
  • [Summary] Constrain the Number of Occurrences of Elements in your XML Schema
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: Re: extending enumerated lists with xsd:union
• Next by Date: Re: extending enumerated lists with xsd:union
• Previous by thread: RE: [Summary] Constrain the Number of Occurrences of Elements in your XML Schema
• Next by thread: RE: Constrain the Number of Occurrences of Elements in your XML Schema
• Index(es):
  • Date
  • Thread