Lists Home |
Date Index |
- From: "Oren Ben-Kiki" <firstname.lastname@example.org>
- To: "XML List" <email@example.com>
- Date: Mon, 8 Feb 1999 23:42:16 +0200
Tyler Baker <firstname.lastname@example.org> wrote:
>Of course the forward slash character is not a valid name character so you
>are pretty much screwed as far as this is concerned....
>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.
Sigh. OK, let's get formal: A valid extended name would be one of:
- A valid XML 1.0 name without any ':' character; or
- A prefix containing any character at all except for '^', followed by a
single '^', followed by a valid XML 1.0 name without any ':' characters.
>> >You would need to change the Document interface to have
>> >createElement() be of the form:
>> >Document.createElement(String prefix, String namespace, String
>> I wouldn't mind such a change - or other extensions to the API to
>> support namespaces. I'm just not convinced that you couldn't _make due_
>> the current API in the mean while (barring small relaxation in what is
>> in a name).
>Above example explains the need.
Sorry, I still don't see why.
>> >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
>> 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
>totally lose track of all of this stuff. Things in effect become
Sorry? Since all the in-memory names are extended, you can cut and paste to
you heart's content without effecting validity. Prefixes only become
interesting when you parse/emit the nodes. The output module would use
'xmlns' attributes left over from the input or added during the mutations as
a guide to which prefixes to use, and if failing that would invent some
prefixes of its own. This way, if the prefixes in the output matter a lot to
you, just add 'xmlns' attributes where needed. Again, future APIs could help
attach these 'xmlns' attributes where appropriate. But existing
non-namespace-aware programs _will go on working_.
How is that unmanagable?
>> Why make this more complex then it has to be?
>I agree, however the "Namespaces in XML" introduces so many problems that
>at the application level is practically unavoidable as things currently
stand. This is very
I guess we'll just have to agree to disagree on this one - unless you can
come up with a concrete example.
Share & Enjoy,
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)