Re: Namespaces and ixml

Steven Pemberton <steven.pemberton@cwi.nl> writes:
> I proposed a way of doing namespaces using the existing mechanisms:
>
>  data: @xmlns:iso, iso:date+.
>         @xmlns:iso: ^"http://example.com/ns/date".
>  iso:date: ...etc...

You don’t say so, but I assume this example is based on “:” having been
added to namefollower. I would like to voice my appreciation for
Michael’s apt summary of that proposal: you must be joking.

> My feeling is that even if there were another notation added as well
> for namespaces, the method above would have to work anyway. So why
> would we want to have two methods of doing the same thing?

I object in the strongest possible terms to using “@” marks for
namespace declarations of any sort. Namespace declarations *ARE NOT*
attributes in any modern XML data model, irrespective of what they may
look like in the serialization.

It is my very strong opinion that ixml must reject any attempt to make
an attribute named “xmlns” or any attribute that begins “xmlns:”. They
are not attributes!

I am also very strongly opposed to any proposal that simply adds “:” to
the namefollow characters. Qualified names *ARE NOT* simply names with
colons in them in any modern XML data model.

I think I’ve demonstrated that the simple namepaces proposal makes a
few, small changes to the grammar (and by implication from the size and
nature of those changes, would not be burdensome to implement) and that
it imposes absolutely no changes to the grammar or the output for users
who refrain from using namespaces. At the same time, its design assures
that the resulting output, in cases where users do *choose* to use
namespaces, will result in a namespace well-formed data model amenable
to downstream processing by common tools.

A proposal to allow random names to contain colons and to provide the
appearance of namespace declarations by constructing “attributes” with
names that correspond to the names of serialized namespace declarations
is not simply flawed in design, but it is a potential nightmare for
implementors *and* users. It requires implementations to track an ad-hoc
collection of namespace declarations randomly throughout the grammar and
users to deal with nasty error conditions when they happen not to put
the declarations in right place. And unlike XML where “the right place”
is easy to describe, and unlike the simple namespaces proposal which
requires them to go in “the right place”, in a grammar where they’re
scattered about randomly, the right place is going to be, at least
potentially, much harder to describe.

If you object to a proposal that addresses the requirements that some
users will have to produce namespace well-formed XML in a way that is
consistent with the XML data model of modern applications, and if you’re
prepared to block the CG from achieving consensus on such a proposal
when you are, as far as I can tell, the only member not in support of
the proposal, then it will not require much discussion: the proposal
will fail to achieve consensus and the status quo will remain.

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica