Lists Home |
Date Index |
On Tue, 2002-05-14 at 18:46, Ronald Bourret wrote:
> As far as I can tell, the PSVI contains three groups of information:
> 1) Additional data values (defaults). Since this already exists with
> DTDs, it seems any controversy here should have existed before the PSVI
> came to being.
I don't think the controversy was clearly recognized until recently.
The killer for this on DTDs for me was the "non-validating parsers not
obligated to read external subset" clause, which made it downright
dangerous to rely on this behavior.
RELAX's avoidance of this 'feature' was pretty clearly a step forward,
IMHO. It might not be a bad idea to create a simple language that
specifies default values of elements and attributes - and does nothing
else - implemented through XSLT. (I hope someone's done that, but my
memory's failing me now.) That would provide the functionality but also
make clear that it requires a particular application context - both good
> 2) Type information. My guess is that this is where the greatest
> controversy / utility is. On the utility side, it means you can do
> type-aware programming. On the controversy side, it means you can do
> type-aware programming :)
Markup lets you identify types with these funky things called element
and attribute names. You can provide extra information about elements
with attributes, but extra information about attributes - uh, where does
it go? DT4DTD gave it a shot, but I just don't think it works too well.
Using DTDs to identify ID attributes has also been a problem for XSLT.
There are lots of people who want to slap their existing typed data into
markup without switching from a OOP or RDBMS notion of types to a
recognition that "element type declarations" are what they say they
are. To me, this suggests these people haven't thought through why
they're using markup in the least, and that seems plain old dangerous.
(Sadly, it's dangerous both to them and to XML - damaging both XML's
reputation and inflicting enormous specs on what was in theory supposed
to make markup _less_ complicated but still powerful.)
> 3) Validation information. Other than wasting space, my guess is that
> virtually everybody will ignore this. It seems that the only people who
> would be interested are a very small group of applications such as
> validators and editors who want to tell the user where their document is
I don't have much trouble with anyone doing yes-no validity, whatever
toolset they choose. Keeping that information around? Error messages
and warnings in attributes seem appropriate.
The more exciting flip-side to this is issues of partial validity. Rick
Jelliffe's pretty convincing on the possibilities of both partial
validity and partial well-formedness, but it's kind of a dark area that
specs don't seem to want to ponder too deeply.
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!