RE: Enlightenment via avoiding the T-word

[Evan Lenz <elenz@xyzfind.com>]

Rick Jelliffe wrote:
> > Rick, I think there is a slippery slope between what you're
> arguing and an
> > even more restrictive use of markup than what DTDs allow. DTDs
> let me put
> > the same element name in different contexts. If you want a
> purer grasp on
> > "meaning" given only the ulabel, a surer bet would be to never
> use the same
> > element name in more than one place. Then you can be sure that
> the content
> > models will not diverge based on their context, now or in the future.
>
> Red herring.

Is it? Then what's the concrete distinction between what I describe above
and what you're defining as good practice? In other words, when is it okay
to use the same element name in different contexts? I can pretty much force
the DTD to accept whatever I want, even if I have to resort to ANY, so
DTD-compatibility can't possibly be the measure of good practice here.

Local element t**** in XML Schemas is one way of supporting a certain kind
of markup. It seems pretty circular to say that what constitutes bad markup
is what XML Schemas allows you to do, and that XML Schemas should not be
required to support bad markup. You must be making a claim about what's bad
markup outside the context of a schema language, but I haven't heard any
concrete rule, only subjective guidelines that are open to interpretation,
hence "slippery slope"...

> The route of requiring some processor to process a
> marked up document and add properties which can be used for
> subsequent processing has been tried before: ISO SGML LINK
> feature (which found no success, in part due to the limited
> selection mechanism), ISO Architectural Forms (which found
> limited success, in part due to the limited selection mechanism),
> and XSLT (which has found success with the rich selection
> mechanism of XPaths.)

I'm afraid I don't follow the connections you're making here. Might you
elaborate? BTW, I was hoping that my last email's P.S. would make clear that
I am not too fond of the PSVI. And I don't see how local element t****
necessitate the PSVI any more than global element thingys.

> W3C Schemas has a weak selection mechanism for types: just use
> the parent.

I will get a better feeling for this once I start using schemas, but,
instinctively, this seems like a good compromise. It does imply a certain
set of practices--practices that are pretty common, I think. In other words,
the maximum contextual information you can use in specifying the content
model is the parent element. This seems to nicely overcome my annoyance with
global-only thingamajigs in DTDs. (Dare I call it an 80/20 point...no, I
wouldn't want to be quoted saying anything like that about XML Schemas.)

> In fact, LINK probably allowed a more sophisticated
> selection mechanism than XS--it allowed you to link in (e.g.,
> fixed) attributes depending on whether the a child was the first
> child of a parent even AFAIR.

I would venture to say that this is an example of a practice that is *not*
common, nor something that I would recommend in either document- or
data-centric environments. Thus, if people are doing such things, they will
need to do a union of the content models with the result being a little less
powerful validation. I certainly can live with that. Yes, I agree that XML
Schemas should not be required to support bad markup.

Evan Lenz
XYZFind Corp.