[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML Schemas: Best Practices
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: "Roger L. Costello" <costello@mitre.org>, xml-dev@lists.xml.org
- Date: Tue, 09 Jan 2001 15:21:21 -0600
Short answer:
No recommendation. Practice must suit requirement.
********************************************
Long answer:
It depends as I said before on whether the
type maintenance is needed and will be expressed
in the schema say, vs constraints expressed in
an application rule.
IOW, the question is really, when does one
need abstract types? Obviously, abstract types
means someone has been negotiating an abstraction
(a compression of representation).
If the hard requirement is for variable content
from non-communicating sources, you are down
to the OR group (doesn't care - it groups, it doesn't
compress the representation).
Aside from compression, you have to ask
yourself what you are going to do with the schema
over time. IMO, a Best Practice can't be divorced
from the rules of the environment of the practice
of combining sources. My experience heretofore with
SGML was that systems needing DTDs needed agreements
apriori. That is what makes them tough to build;
the politics of agreement, but this was before XML
became a messaging format. In SGML, it was a contract
among companies or customers to enhance lifecycles
for documents. That is the real reason only
the bigGuys did it. Few others needed it enough
to pay for it.
On the other hand, when I've had to
o initialize an authoring system with it (eg, think
ArborText or Softquad editors that are DTD enabled)
o aggregate in a stylesheet enabled player which
got rid of the need to downtranslate (eg, to HTML)
and there are multiple, equal authorities controlling
the content, I used the OR group to switch sets in and
out. In an situation with equal probabilties, the
rule of choice is an external authority/system (eg, the
workflow system rules the content of the document).
Using the OR, a DTD controls a set of multiple document types that
share sub-trees. The choice of type depends on the
what content type is requested. I did this both for US Navy
Work Package systems (CASS) and US Army DTDs for IADS
because each of the document families was as you say,
under different controlling authorities but the actual
document had to be authored as if it were one document. The only
reason to combine them was their contents are shared
in the target player (IADS in the second case) which
was stylesheet-enabled and frame targeted, or the authoring
tool used by one group all the time (CASS). In other
words, we were not downtranslating; we aggregated.
That is quite a different issue from using a schema
as a sort of object hierarchy declaration or to feed a
transform. In short, remember that a schema is a
formal description and the "bestness" of the practice
has to be defined in terms of the environment of
the requirement of use or the local rules of the
thing described. We have multiple means because
we have multiple overlapping but distinct requirements.
BTW: I've never cared for entity based
modularization. It is ugly to teach, ugly to use,
and ultimately, it seems, only helps the DTD maintainer
keep up with abstract grouping names. I prefered switching
tags that at least make the GUI look more sensible
by clearly showing it was a choice, not an object.
PE modularization has always looked like a hack to
me; useful but asserting the DTD is a better description
than it actually is. I am in the minority on that
position because switch tags result in crud in the
file which the semantic or style processor has to ignore.
Some early systems used to stick a non-displaying but
format affective (space, line end, etc) in there anyway
and the rules for the formatting stylesheet could get ugly
keeping that out. On the other hand, say using XPath, a
switch tag can be convenience. We ended up with
them in X3D to make the multiple encoding madness
easier to live with, thus
<children>
is in there although one wishes it weren't. Now that
schemas enables abstract types (X3D is an abstract
node language from the get go), we can make those
go away.
Len
http://www.mp3.com/LenBullard
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
-----Original Message-----
From: Roger L. Costello [mailto:costello@mitre.org]
Of the 3 methods, which one would you recommend for Best Practice Curt?
Len, what's your recommendation? /Roger