[
Lists Home |
Date Index |
Thread Index
]
At 16:50 +0200 2005-04-19, James Fuller wrote:
>Saha Rabindra N wrote:
>
>
>>>Hi All,
>>> Can somebody tell me the real use of xml namespace in xml domain only.
> >>I know that xml namespace is useful in xsl.
...
>XML namespaces exist to avoid name collisions.
That's the key idea (IMHO).
If you have your schema, and I have mine, and we never have to share
data, then namespaces may not be hugely useful. But if we eventually
have to share our data, somehow we have to resolve cases where we use
the same names to mean different things.
In that case, one of us can rename the elements in our data -- but
that means *touching* the data, which risks corrupting the data no
matter how careful we are. Instead (and somewhat simpler), we can
assign our elements different namespaces:
mine:title may be somebody's job title on their application form
your:title may be a book title in a bibliography database.
If you use inheritance as much as possible for the namespace
prefixes, this greatly reduces how much you have to touch the data.
If you set up default attributes in your DTD you may not have to
touch the data at all, which is ideal.
As James pointed out, namespaces also make it feasible for someone to
create a nice schema for one particular thing, and let other people
use it as a part of their schemas, without having to worry about name
conflicts.
For example, a number of other schemas have adopted HTML's markup for
tables (and another bunch use "CALS" tables, but that's another story
I'll tell you over some beers sometime). If you code:
<!ATTLIST table CDATA "xmlns='http://ns.example.org/html-tables'">
Assuming you are using a parser that deals with the ATTLIST
declaration, this will cause all <table> elements in the document to
default to the meaning called "http://ns.example.org/html-tables";.
And then if you don't put namespace prefixes on any elements *within*
the tables, they'll inherit the same namespace.
The end result is that you can paste in your HTML tables without
having to tweak them at all. This makes it much clearer what's going
on, *and* it enables processors to detect what you're doing. For
example, a tool that can extract information from HTML tables (or
format them, or encrypt them, or sign them, or whatever), can
reliably find them, despite their being embedded in documents with
lots of other stuff going on.
This is useful. It would be more immensely useful if we had some nice
standardized schema-bits for common elements such as addresses,
bibliography entries, lists, appointment item, itinerary,
product-catalog entry, and so on.
Steve
--
Luthien Consulting: Real solutions to hard information management problems
Specializing in XML, schema design, XSLT, and project design/review/repair
Steven J. DeRose, Ph.D., sderose@acm.org
|
