[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Namespaces Not Necessarily Unrepentant Evil
> >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 [expletive deleted] 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|