[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Fw: "Clean Specs"

• From: "Oren Ben-Kiki" <oren@c...>
• To: "XML List" <xml-dev@i...>
• Date: Mon, 8 Feb 1999 23:42:16 +0200

Tyler Baker <tyler@i...> 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@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Fw: "Clean Specs"
    • From: John Cowan <cowan@l...>

• Prev by Date: Re: A New Hope (was Re: Storing Lots of Fiddly Bits (was Re: What is XML for?))
• Next by Date: URL: 19 Short Questions about Namespaces (with Answers)
• Previous by thread: Re: Fw: Fw: "Clean Specs"
• Next by thread: Re: Fw: "Clean Specs"
• Index(es):
  • Date
  • Thread