Lists Home |
Date Index |
- From: "Ogievetsky, Nikita" <firstname.lastname@example.org>
- To: "'email@example.com'" <firstname.lastname@example.org>
- Date: Tue, 9 Mar 1999 16:54:20 -0500
Richard L. Goerwitz wrote:
>Ronald Bourret wrote:
>> > I have several DTDs with conflicting definitions of certain elements.
>> > ...Am I going to have to break down and just rewrite the DTDs to use
>> > the qualified names?
>> If you want to use a namespace-unaware parser, I don't see how you can
>> avoid rewriting the DTDs.
>Maybe I misunderstand, but as far as I can see, namespaces won't help
>you, either. Why? Because even if you can refer to, say, your two TITLE
>elements by different prefixes, you'll still have to declare the prefixed
>elements in the DTD as if they were atomic element names.
>Namespaces, in other words, don't solve your problem. They may make it
>worse, in fact, because you have to know what prefixes you are going to
>declare in a given document to be able to rewrite your DTD to work with
I have a similar problem:
On my web site http://www.cogx.com, I am working on XML driven menu bar (can
be a tree, etc)
The underlying XML uses reusable structures such as months, quarters of the
Tax schedules with zillions of tax lines repeated, etc.
Instead of having just one XML document for the menu bar,
I moved reusable fragments into a separate file and access them from
my main XML by
it is also obvious
that I should not keep all fragments in one reusable collection, but rather
separate them by theme. - Why should I send file with tax schedules to a guy
interested in Opera performances?
So I can have as many reusable collections as I wish: tax related,
publications related, theater related, etc...
It means I should allow freedom in specifying namespace prefixes and still
what each prefix means!
I am achieving this by
declaring my namespaces as follows:
the prefix "groups:" tells me that a namespace of reusable fragments was
Now I can give my prefix any name.
When parsing I know that it is a namespace of reusable fragments!
Problem here is that <group> element has to be defined with an open model to
for different namespace prefixes.
I also made a proposal that it would be great to reserve "any" prefix for
this type of situation. This will
save me from using open model, which I do not like, really!
> The most effective responses I saw were
>from people who said, in effect, "Namespaces do far less than you want
>or expect them to."
Exactly! And this is why
Namespaces let you do much more then you thought you can!
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)