[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
> These discuss both the cost of excessive tagging and the human temptation
> to "tag abuse" if the set of legal tags doesn't meet the needs and
> expectations of authors. Schema designers, authors, and those developing
> the software that processes the data all have to work together to find
> the appropriate tradeoffs. As others have mentioned, the right
> balance would be easier to find if widely deployed schema validators
> supported RELAX-like pluggable type systems. If the "idioms" could
> be expressed by declarative formatting rules, then they can
> be enforced more easily by authoring tools in a way that the authors
> won't find onerous.
I am all for pluggable type libraries. Aside from that, any fact that XML
is verbose is not something that we've been too concerned with. (we've all
heard this before). Would you:
a) advocate using attributes over elements because "not having a close tag
means less characters, hence smaller files for transmission across the
network"?
b) any number of binary compression formats
c) short unreadable tag names rather than long verbose tag names
etc.
> ...For example, I presume that most authors would
> find it easier to write:
>
> <position>75°15'00" N 43°05'00" W</position>
>
> than
>
> <position><deg>75</deg><min>15</min><sec>00</sec><dir>N</dir>
> <deg>43</deg><min>05</min><sec>00</sec><dir>W</dir></position>
>
> and would understand the need for rigor and consistency in the format,
> BUT would appreciate being told if they put in a number outside the
> valid range for degrees, minutes, and seconds or a direction other
> than N, S, E, W. I *think* that a RELAX NG-aware editor with a
> custom datatype validator plugged in could do this.
I think that Simon's "regular fragmentations" is a perfect fit here. An
author might quickly type something in which can be 'expanded' into a
structure given a regular expression. Voila' ... best of both worlds.
>
>
> This gets into another issue that I hear about on my occasional forays
> into the Real World but seldom see discussed by XML geeks: Even if
> examples such as these could be handled by pluggable type libraries,
> there are a lot of "business rules" that must be enforced that can't
> be expressed in syntactic constraints. For example, what if a
> "valid" <position> has to be in North America? I sometimes get
> the impression that Real World people just say "fuggitaboudit" and
> constrain the authoring with natural language instructions and
> "validate" (or is this "verify"?) with procedural code. If so,
> how much does all the schema/typing agony that we wrestle with
> really help people do their jobs better? Or rather, what would it
> have to be able to do so that it would help people do their jobs?
>
Yes and the corrollary I'd add is that any short term benefits one might get
with compact syntaxes is usually lost on the long term problem of dealing
with such syntaxes. Time to move onto the harder problems of assigning
semantics to the syntax (e.g. business rules).
That said, I'm all for such things as RELAXNG compact syntax ... which has
an unambiguous representation in XML.
Jonathan
|
