By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,264 Members | 1,056 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,264 IT Pros & Developers. It's quick & easy.

Best practice Questions

P: n/a
Hi,

I am in the process of creating a schema definition to validate some
XML data that will look like the following:

ProductA

SubProductA
SubProductB
SubProductC

ProductB

SubProductX
SubProductY
SubProductZ

Now I would like if possible to create a simple type called say
"Product" which has Enum content of:

Enum:"ProductA"
Enum:"ProiductB"
......
......

Then also have another simple type for the "SubProduct" with it's Enum
values as follows:

Enum:"SubProductA"
Enum:"SubProductB"
EnumL:"SubProductX"
......
I am struggling in deciding the best way to structure the complex Type
so that the Structure is enforcing the fact that SubProductX can only
be a SubProduct of ProductB......

I would like the flexability to be able to simply add a new
ProductType and enforce the relevant subtypes allowed to be detailed
with them.

Am fairly new to XSD (3 Weeks in) Any help much appreciated.

Apr 20 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On 20 Apr, 16:11, jlam...@googlemail.com wrote:
I am in the process of creating a schema definition to validate some
XML data that will look like the following:
Just don't. This isn't an appropriate concept to try and validate
with schema.
Sadly it's too difficult to spend the full time explaining, given
today's workload. Briefly though:

Schema / DTD validates XML _structure_ and not 'data' content. If you
follow your approach here, you're pushing 'data' items into the
structure by using them to generate element names. This would also
permit DTD / Schema validation ("permit", not "make it easy") of your
data rules. However this is also a use of XML that's usually a bad
idea -- you've implemented something that's changeable in practice
(product structure) and nailed it down with something that really
implies long-term stability (XML Schema).

A better approach would be a simple XML Schema based on just <Product>
as an element and keeping ProductA, ProductB etc. well away from this.
This does make Schema-based validation difficult though and starts to
look like a task for OWL instead. Even then, it's still easy to get to
a stage of complexity where it becomes impossible to validate
automatically. Better than fluid element names though.

Apr 20 '07 #2

P: n/a
I am struggling in deciding the best way to structure the complex Type
so that the Structure is enforcing the fact that SubProductX can only
be a SubProduct of ProductB......
That sounds like it ought to be something enforced by your application
code, at least as much because it will change dynamically over time
based on other tables of product relationships as because it'll be a
pain to do in schemas. (You don't want to have to change the schema when
you introduce a new product.)

Schemas are used to define the structure of a language. What you say
with the language is a separate question.

Use the schema system to define the structure of your documents, and
reasonable ranges for their values... but for nontrivial applications,
don't assume it's the only check that will be performed. Your
applications will have to continue applying semantic checks if you want
to make sure the document means something reasonable.
(By analogy: A schema for English would conclude that "colorless green
ideas sleep furiously" is a perfectly reasonable statement, because all
the words are valid and the sentence structure is acceptable. The fact
that it's nonsense has to be dealt with at another level.)

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry
Apr 20 '07 #3

P: n/a
On Apr 20, 8:54 pm, Joe Kesselman <keshlam-nos...@comcast.netwrote:
I am struggling in deciding the best way to structure the complex Type
so that the Structure is enforcing the fact that SubProductX can only
be a SubProduct of ProductB......

That sounds like it ought to be something enforced by your application
code, at least as much because it will change dynamically over time
based on other tables of product relationships as because it'll be a
pain to do in schemas. (You don't want to have to change the schema when
you introduce a new product.)

Schemas are used to define the structure of a language. What you say
with the language is a separate question.

Use the schema system to define the structure of your documents, and
reasonable ranges for their values... but for nontrivial applications,
don't assume it's the only check that will be performed. Your
applications will have to continue applying semantic checks if you want
to make sure the document means something reasonable.

(By analogy: A schema for English would conclude that "colorless green
ideas sleep furiously" is a perfectly reasonable statement, because all
the words are valid and the sentence structure is acceptable. The fact
that it's nonsense has to be dealt with at another level.)

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry
Thanks very much for your responses i'll take that on board.

Apr 21 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.