Lists Home |
Date Index |
- From: Tyler Baker <firstname.lastname@example.org>
- To: Oren Ben-Kiki <email@example.com>
- Date: Mon, 08 Feb 1999 16:23:35 -0500
Oren Ben-Kiki wrote:
> Tyler Baker <firstname.lastname@example.org> 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
> >> 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
> 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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)