Fw: "Clean Specs"

[Oren Ben-Kiki]

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
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.


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
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.


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
avoiding complexity
>at the application level is practically unavoidable as things currently
stand.  This is very
>unfortunate.


I guess we'll just have to agree to disagree on this one - unless you can
come up with a concrete example.

Share & Enjoy,

    Oren Ben-Kiki


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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)