Fw: "Clean Specs"
oren at capella.co.il
Mon Feb 8 21:49:50 GMT 1999
Tyler Baker <tyler at infinet.com> 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:xml-dev at 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 at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev