[
Lists Home |
Date Index |
Thread Index
]
- From: <david@megginson.com>
- To: "XML Developers' List" <xml-dev@ic.ac.uk>
- Date: Fri, 15 Jan 1999 11:52:54 -0500 (EST)
Borden, Jonathan writes:
> I don't see a problem with this one-to-one relationship, after all,
> a namespace *is* defined by a uri, so... and I don't immediately
> see why this precludes inclusion of elemements from different
> namespaces.
What if I want to create a schema specifying that (for my set of
documents) an html:p element may contain a tei:foreign element, or a
docbook:Trademark element in addition to the regular HTML elements?
What if I want to create a schema specifying that (for my set of
documents) an html:p element may *not* contain an html:font element?
It doesn't make sense to have to create a new and different namespace
for either of these -- I'm still using the individual elements in
mostly the same way. I could, of course, use some kind of inheritance
scheme, but I don't think the world will buy anything that requires
retrieving 5 or 10 schemas from different servers just to figure out
that an html:a element is from the HTML namespace.
> I think the idea is that if a namespace is defined by a uri, it may
> inherit a meaning associated with that uri, for example, suppose
> the uri was a .DTD, would this cause a problem or work any less
> well than a DTD which defines a default namespace and is specified
> in a <!DOCTYPE definition?
It would cause about the same set of problems as DOCTYPE (perhaps
worse with datatyping and other niceties) -- that's why we need to get
away from it.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|