/ Jacek Kopecky <jac...@systinet.com> was heard to say: | had the DocBook schema been designed to allow for arbitrary | extensibility in an other namespace, the added element (or | attribute) would be the solution.

No. I gave several reasons why an element from another namespace is not and would not be a reasonable solution to this problem.

An namespaced attribute would have fewer of the problems, but I think that's inappropriate as well (and it *only* works if you have a schema that you can change or a schema that was designed to allow the solution you suggest). A PI works everywhere, for anyone.

| Yes it would not validate against the original schema, but this | is not a raw DocBook document, it is a document extended with | information for transformations. Why not admit that and create a | schema that allows attributes (or elements) from the known | extension namespace (here prefixed dbhtml)?

For reasons 1-3 that I gave before. Besides, it *is* a DocBook document. No harm results from ignoring the PI.

| I've used an attribute here and not an element because this | parameter is actually an attribute of the list, not a member | thereof. That's also the wrong thing about PIs - it's usually | working as a switch acting "on the following siblings", not "on | the children of the switch" or "on the parent element of the | switch", both of which would IMHO be more XML-ish.

IMHO, siblings and children are equally accessible. Containment is useful, but not necessary.

| Alternatively, you could create an other file which would list | which variablelists should be formatted as tables, for example as | tuples of an XPath expression and a list format type. The | stylesheet could then heed that information. I think you might | have suggested this approach below, actually.

Yes, that's one out-of-band solution.

| You already said that you have to change your stylesheet to | check for that processing instruction, so I don't see why it | would be substantially worse to have to change the stylesheet to | check for a known element (or attribute) and not process it using | the default rules. If this is considerably more complex in XSLT | (or whatever you use), then it's a problem of XSLT, not of XML, I | think.

Because an unknown PI is likely to be ignored or transparently passed through. An unknown element is likely to screw all sorts of things up (like the count of element children, the preceding and following elements of its siblings, etc.).

In other words, I have to change my single stylesheet to *look for* the PI. This is very different from changing *every stylesheet* *to ignore* the namespaced element.

| If you decided to throw away XML's namespace extensibility in | *all* your stylesheets (by adding the default rules copying and | quoting the tags into the result document), well, you've closed | one door before yourselves.

Extensibility is a good thing. I certainly make use of it. It does not follow that uncontrolled extensibility is appropriate in every context.

Be seeing you, norm