Namespaces Not Necessarily Unrepentant Evil

[Paul Prescod]

> >Again, my apologies to those who I badgered inappropriately.
> 
> Not required. -Tim

Aren't we a cosy little family. I'm glad to take humility from Eliot
whenever I can get it.

Tim Bray wrote:
> 
> >4. Name spaces take away authorial choice of element type and attribute
> >names.
> 
> No, just of the prefix.  I expect that once we have namespace-aware
> schemas, they will never contain a prefix, so the document designer
> and author should think entirely in terms of <start-time> and <duration>
> and so on, and if when a chunk of that markup gets assembled into a
> package for delivery, if those become <sex:start-time> and <sex:duration>
> who cares?

I think that Eliot's point is that architectural forms and other, similar
mechanisms, allow name remapping in constrained ways which allow authors
to use their own names and still be confident that their document conforms
to some industry or departmental DTD. In my mind, markup users always walk
a fine line between "doing their own thing" and "following the standard."
"Doing their own thing" is crucial, because generic markup exists
*precisely* to allow them to do their own thing -- they know their data
better than some industry consortium (or department manager). But standard
exist because doing too much of your own thing imposes unreasonable
burdens on the cost effectiveness fo the system.

Let's call this the "Balance of Power" problem. To me, this is the
fundamental problem of generic markup. Little guy needs to protect his/her
data from overstandardization. Big brother needs to protect his/her system
from creative rebels.

I think that this is the root of Eliot's complaint about namespaces. They
increase one side of the equation but leave the other side gasping. They
should be balanced by a counter-move that increases the freedom of the
author/department/corporation inside the department/corporation/consortia.

Subclassing:

Subclassing in modern schema proposals is *supposed* to increase the
freedom of the author/department etc., but mechanisms in existing
proposals go only half-way. They do not seem to allow renaming,
reordering, etc. of elements in subclasses. I admit that this is a hard
problem, and would not vote against a proposal that does not tackle it.
Let's just be clear that we are only solving half of the problem.
Eventually, we must allow these sorts of "language redesigns" to take
place as close to the author as possible, but also offer Big Brother the
assurance that the language redesign does not destroy the consistency of
the system.

Oh yeah, and open content models suck rocks. Big time. Really.

XSL:

Does the XSL transformation language help?

I believe that given our current level of knowledge, the XSL
transformation language goes too far the *other* way. Nobody currently
knows how to verify that a document that conforms to a DTD A will conform
to a DTD B after going through an XSL transformation without doing the
transformation. This means that authors who use XSL transformations to get
to industry standard DTDs must constantly do the transformation to check
that they still conform. This is unacceptable for solving the problem I
described. In this context, XSL is a gun aimed at the foot. 

If someone wants to sponsor 3 months of research, I will be happy to
develop algorithms that can predict whether an input document will conform
to an output DTD after an XSL transformation, without doing the
transformation (as long as XSL doesn't get more complex in the meantime!).

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Everything I touch turns into Python.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)