[
Lists Home |
Date Index |
Thread Index
]
[Rick Jelliffe]
From: "David Carlisle" <davidc@nag.co.uk>
> Take a look at the namespace spec.
> Namespaces are not about semantics they are about names.
Well, they really are about modularity which cannot really get too far from
ideas of semantics.
[Tom P]
From a strict point of view, the modularity is on a syntactical level,
though, not a semantic level. If I specify an ex:address element rather
than an xy:address element, I am specifying the __structure__ of the address
element and its children. This lets me know how to process its structure.
It is inviting to assume that any semantics that originally attached to the
ex:address element should come along with my use of it, but the Recs say
nothing about that. Since neither XML Schema, DTDs, nor RELAX NG specify
semantics, there is no standard mechanized way to specify or control the
semantics of a document design.
Suppose that we import an ex:person element and it has an attribute "id".
The original schema had an annotation saying that the id is intended to be a
(US) social security number. But after we have started to use our schema,
we decide to that it needs to allow either an SS number or the person's
driver license number (in many US states you can use state-assigned number
in place of your SS number for a driver's license). Should we stop using
ex:person? This is a semantic issue, not a structural or syntactical one
(and gets into Len's pet area of contracts).
Suppose that we decide to continue to use the id attribute even though its
meaning has changed a bit. The syntactic consequence is that ex:person will
still work fine with my software. If we decide that we should have another
attribute, called "newid", that would be a semantic decision and we could
work out the syntactical consequences (perhaps an extension of ex:person if
it can be extended).
Of course, we may consider the syntactic consequences as we decide whether
the semantic issues are strong enough to warrant a change in the structures.
Those practical tradeoffs are where the lines get blurred. But I think it
is useful to start from a strict position - syntax is syntax, not
semantics - and only deviate for good reasons. The Recs - XML, Namespaces,
Schema - only deal with syntax. The semantic issues are an overlay.
Cheers,
Tom P
|
