DTD design practices

[Girish Sharma]

I'm new to using XML. I am currently required to use dtd's rather than
schemas. I have some questions about what is considered appropriate design
with a dtd. It seems that none of the following are enforced by the dtd
during a standard validation:

1. Using the value of attributes to constrain which of the optional child
elements are allowed to be used.

2. Restricting the number of a particular element that can exist with a
particular attribute value.

3. Restricting which of some optional child elements are allowed based on
the context (the grand-parent element) of the parent element.

Is creating a dtd that uses these concepts, even though they are not
enforced during standard validation, considered less than optimal design?

Are there commonly used alternatives to the above that do allow for dtd
enforcement?

I'm wondering for example for number 1, instead of attribute values using
optional child elements that correspond with each of those values. Then each
of those child elements can in turn can have the desired child elements for
that situation. It could result in a large number of the "intermediate"
child elements if there are many possible attribute values.

For number 2, is there any way to accomplish that using child elements
instead of attribute values?

For number 3, it seems that changing the parent element into several similar
elements and then using the appropriate one in the correct context. If
carried to an extreme though, there would be no optional child elements at
all - only different parent elements. But my question relates specifically
about always being required to use particular optional child elements based
on context.

Thank you.

Girish Sharma

[Joe Kesselman]

Girish Sharma wrote:

It seems that none of the following are enforced by the dtd
during a standard validation:
DTDs are pretty basic; they provide only structural constraints, not
interactions.
Is creating a dtd that uses these concepts, even though they are not
enforced during standard validation, considered less than optimal design?
Absolutely not; that's entirely reasonable. Remember, the DTD -- or the
schema -- is only the first stage of validation, just enough to provide
some guidance to folks authoring documents or tools to create them.
Think of them as higher-level syntax constraints; your application will
almost always impose semantic constraints on top of those.
Are there commonly used alternatives to the above that do allow for dtd
enforcement?
Different element names can be used for the differently constrained
versions. (or the sort of child-element structuring you suggested). ID
attributes can be used when you need to ensure that an attribute value
is unique in the document (though that's unique for all ID attributes in
the entire document, not just instances of that attribute name). Other
than that... Enforce it in the application.
For number 2, is there any way to accomplish that using child elements
instead of attribute values?
Nope.
For number 3, it seems that changing the parent element into several similar
elements and then using the appropriate one in the correct context. If
carried to an extreme though, there would be no optional child elements at
all - only different parent elements. But my question relates specifically
about always being required to use particular optional child elements based
on context.

If it makes sense semantically for the language you're creating, you can
do it that way. If it doesn't, don't -- enforce in the application
rather than in validation.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Peter Flynn]

Girish Sharma wrote:

I'm new to using XML. I am currently required to use dtd's rather than
schemas. I have some questions about what is considered appropriate design
with a dtd. It seems that none of the following are enforced by the dtd
during a standard validation:

1. Using the value of attributes to constrain which of the optional child
elements are allowed to be used.
No. You have to use a Schema if you want to do this level of validation
at document-creation time.
2. Restricting the number of a particular element that can exist with a
particular attribute value.
Only in that the ID type attribute constrains the values to be unique
per document.
3. Restricting which of some optional child elements are allowed based on
the context (the grand-parent element) of the parent element.
No. Element content models are a flat address space. You can't have
an elements declared to use one content model in one circumstance,
and a different content model in another. But you can probably fake
it using Namespaces :-)
Is creating a dtd that uses these concepts, even though they are not
enforced during standard validation, considered less than optimal design?
It depends on why and where you need to check the values. If you need
to impose the checks during document creation, you'll need a Schema.
If you only need to check them after creation (and route any failed
documents back to the author for amendment) you can write the checks
into a script in XSLT instead.
Are there commonly used alternatives to the above that do allow for dtd
enforcement?
Schemas. Or postprocessing.
I'm wondering for example for number 1, instead of attribute values using
optional child elements that correspond with each of those values. Then each
of those child elements can in turn can have the desired child elements for
that situation. It could result in a large number of the "intermediate"
child elements if there are many possible attribute values.
Yes, that's possible, with the disadvantages you cite.
For number 2, is there any way to accomplish that using child elements
instead of attribute values?
Yes, same as above, but DTDs only allow occurrence indicators
for optionality and multiple occurrence, not counted occurrences.
For number 3, it seems that changing the parent element into several similar
elements and then using the appropriate one in the correct context. If
carried to an extreme though, there would be no optional child elements at
all - only different parent elements. But my question relates specifically
about always being required to use particular optional child elements based
on context.

That's the same concept as before.

In summary, it's probably possible to do what you want, but it would be
pretty clumsy. But if you are constrained to use DTDs that may be your
only option.

///Peter
--
XML FAQ: http://xml.silmaril.ie/

[Girish Sharma]

Thank you for the helpful replies to my questions.

Girish Sharma

"Girish Sharma" <re***************@earthlink.net> wrote in message
news:2o*****************@newsread1.news.pas.earthl ink.net...

I'm new to using XML. I am currently required to use dtd's rather than
schemas. I have some questions about what is considered appropriate design
with a dtd. It seems that none of the following are enforced by the dtd
during a standard validation:

1. Using the value of attributes to constrain which of the optional child
elements are allowed to be used.

2. Restricting the number of a particular element that can exist with a
particular attribute value.

3. Restricting which of some optional child elements are allowed based on
the context (the grand-parent element) of the parent element.

Is creating a dtd that uses these concepts, even though they are not
enforced during standard validation, considered less than optimal design?

Are there commonly used alternatives to the above that do allow for dtd
enforcement?

I'm wondering for example for number 1, instead of attribute values using
optional child elements that correspond with each of those values. Then
each of those child elements can in turn can have the desired child
elements for that situation. It could result in a large number of the
"intermediate" child elements if there are many possible attribute values.

For number 2, is there any way to accomplish that using child elements
instead of attribute values?

For number 3, it seems that changing the parent element into several
similar elements and then using the appropriate one in the correct
context. If carried to an extreme though, there would be no optional child
elements at all - only different parent elements. But my question relates
specifically about always being required to use particular optional child
elements based on context.

Thank you.

Girish Sharma