[
Lists Home |
Date Index |
Thread Index
]
I've been trying to follow all this RDDL/Namespace/doctype stuff. I'm having
a hard time, and it may be due to stupidity or ignorance (me, I'm talking
about, not you people), or it's just that I have a different conceptual
background than many on this list.
So let's see if I can get my concepts (flawed though they may be) to map to
what's being discussed in these tangled threads.
Let's start with definitions of terms. These are terms as I understand them,
and YMMV. You formalists out there should feel free to offer refinements or
corrections. I'll feel free to ignore your corrections on grounds of
preferring clarity over precision ;->
Domain
- A named set of entities, commonly-understood by the domain's experts.
Entities are unambiguous within a domain. This implies that no two entities
of the same name but different properties exist within a domain.
Superdomain
- A named set of subdomains. Entities within the superdomain are commonly
understood by domain experts.
Domain span
- A set of subdomains. May or may not be named. Used to conveniently refer
to disparate domains that may only be temporally related. A domain span is
flexible and effervescent, a superdomain is less so.
Entity
- A named set of properties. Entities may also have behaviors (methods) in
some physical models (but not XML). The properties of an entity define its
type.
Property
- a named set of atomic values. Values have a datatype.
Datatype
- Well-understood atomic valuespaces.
schema
- a set of definitions for entities
Okay, the above are pretty lightweight, definition-wise, but let's see if I
can tie them together in a consistent, unambiguous manner...
The company I work for is primarily concerned with the print manufacturing
domain. That means we take document content (PostScript and PDF) and add the
geometry to it to produce press sheet flats (signatures) that can be printed
on a press, folded, and trimmed into book sections. We do other stuff, too,
related to print manufacturing, but that's the core of it.
Now, the word "signature" in the print manufacturing domain has different
properties (has a different definition, or meaning) than the same word in,
say, the object-oriented programming or legal domains.
XML Namespaces allow me to distinguish my "signature" from some other
namespace's "signature" by changing it's identifier. It allows me to do this
by adding a QName to my local name. This way, my "{qname}signature" is
globally distinguished from other "signatures" in other namespace's.
Notice that the word "domain" was not mentioned in the above paragraph.
That's because a namespace does not identify a domain. It is merely
(strictly speaking) a disambiguation device. It has no meaning *by
definition*. Now, others may want to add meaning to it, and they're free to
do so (if they can stand the consequent heat).
Schemas define entities. It is possible that a schema defines entities for
one namespace or one domain, or both. It is also possible that it doesn't.
It may define a domain span, such as a schema for a report that is to be
generated that pulls together data from disparate domains. Or it may define
a superdomain, in which it contains not only it's own namespace, but the
namespace of the schemas it includes (assuming those subschemas define
entities in other domains or superdomains).
What we don't seem to have in XML is a way to consistently represent this
notion of domain. That's either because the definitions I've outlined above
are too fuzzy to be of use, or it's because we don't have many here on this
list familiar with data modeling concepts.
I dunno, but the concept of domain seems central to my way of thinking. I
work in an industry that, when I say "signature", means one specific thing
(or class of things). I have a way in XML to disambiguate my signature from
you're signature, but not a way to say "In my domain, signature means
this...".
Sure, I can write a schema to define my domain entities, but their's no
schema mechanism that enforces direct mapping to one specific domain, or to
let someone know that it defines a domain. We have this doctype notion, but
that's not quite it, either.
What do I want:
I want to say:
"this is my domain; it's name is __; it's description is ___"
"these are the namespaces in my domain"
"this is the schema(s) that defines the entities in my domain"
"these are the schemas that define domain spans, but are not domains of
themselves"
(you could quibble with the above [x schema is in report x domain] but I
think the distinction between domain span and superdomain is valid)
Maybe something like RDDL (or RDDL++) can do this, but I think we need
something canonical here. And whatever mechanism it is, it shouldn't be
forcefed to those who aren't interested. Layer it on top. Make it a domain
model layer on top of existing specs, if possible.
|
