Fw: Fw: "Clean Specs"
oren at capella.co.il
Mon Feb 8 20:46:06 GMT 1999
Tyler Baker <tyler at infinet.com> wrote:
>What I am saying here is that if you make a call to:
>What are you to do here? Do you throw in an expanded name,
That's what I had in mind.
>or do you throw in a QName which
>should be expanded by the DOM?
Not using the current API.
>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.
>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 :-)
>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).
>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?
>> 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?
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