xml-dev - Re: Fw: Fw: "Clean Specs"

[Tyler Baker <tyler@infinet.com>]

Oren Ben-Kiki wrote:

> Tyler Baker <tyler@infinet.com> wrote:
> >or else would I do something like:
> >
> >String namespace = "http://www.w3.org/TR/WD-xsl";
> >String localPart = "text";
> >Document.createElement(namespace + ":" + localPart);
>
> Using '^' instead of ':', that's exactly what I had in mind.

Fair enough (but not compatible with XML 1.0).

> >Of course the forward slash character is not a valid name character so you
> are pretty much
> >screwed as far as this is concerned.
>
> If the only change we'd be requiring in the DOM is allowing '/' in names
> before a '^', then we are in a pretty good shape :-)

This is only one of many characters.  A namespace can be anything you want it to be.  It could
be just about any sequence of unicode characters you can think of.  You would have to restrict
a namespace to be only valid NCName characters.

> >You would need to change the Document interface to have
> >createElement() be of the form:
> >
> >Document.createElement(String prefix, String namespace, String localPart);
>
> I wouldn't mind such a change - or other extensions to the API to _better_
> support namespaces. I'm just not convinced that you couldn't _make due_ with
> the current API in the mean while (barring small relaxation in what is valid
> in a name).

Above example explains the need.

> >The prefix would be there for backwards compatibility.
>
> Just don't delete the 'xmlns' attributes when extending the names. The
> output XML write would be able to use them as a guide to how to generate the
> output XML. Future API calls may use these attributes to provide more
> convenient namespace specific functionality. So?

xmlns: attributes are inherited.  When you copy and clone nodes all over the place (one
application of XSL I know of does this when constructing the source tree programmatically) you
totally lose track of all of this stuff.  Things in effect become unmanageable.

> >> I _really_ wish this whole namespace recommendation was specified this
> way
> >> from the start.
>
> To clarify: If it was specified as being equivalent to a purely textual
> transformation, then only very slight modifications or none at all would
> have been required for current APIs and standards. Yes, XSL would need
> namespace matching patterns. Yes, _in-memory_ names could include anything
> until a '^' character, and only from then would be limited by XML 1.0 rules.
> These seem relatively minor changes. Otherwise, things would just go on
> working.
>
> Why make this more complex then it has to be?

I agree, however the "Namespaces in XML" introduces so many problems that avoiding complexity
at the application level is practically unavoidable as things currently stand.  This is very
unfortunate.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)