[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] xmlns empty string
- From: noah_mendelsohn@us.ibm.com
- To: Ran <ran256@gmail.com>
- Date: Thu, 21 Dec 2006 11:00:11 -0500
ran writes:
> What is your suggestion on using <include /> v.s. <import /> ?
Well, my suggestion is that you should approach this mainly as an XML
question, and only secondarily as a schema question. Presumably you are
designing the markup to be used in some set of related XML documents. So,
you need to decide whether the names of those elements should be in
namespaces at all, and if so whether they should be spread across more
than one namespace. That's a decision you'll have to make independent of
whether you ever write a schema for anything. In general, putting each
element into some namespace is good practice, unless you're really just
using the XML in a local environment such as for hacking on your own
desktop. Reason: if anyone ever stumbles over one of your documents,
there will be no ambiguity about what the element names are. In some
random document, an unqualified element name like <title> could mean a
person's title, a books's title, etc.
As to whether to use more than one namespace, the usual reasons are if
your documents are going to be mixing in element names that seem to
related to solving quite seperate problems, or if you expect to reuse the
groups of names in different combinations, a separate namespace might be
good. So, let's say you are working an an XML language suitable for
setting down works of music in music notation (there are some emerging
standards for this, but you've decided to invent your own anyway). You
decide your documents should also be version-controlled, so you invent
some elements to control the versioning. Ask yourself: would I like to
reuse these same version control elements for something unrelated to the
music language? If so, that might be a good hint that putting the version
control elements into separate namespace would be appropriate. Of
course, if you are bringing in elements invented or controlled by others,
say you're embedding some HTML tags for your documentation, then you'll
definitely be using separate namespaces for those, and indeed you'll
almost surely be importing a schema someone else wrote.
Back to your question: import or include in your schemas? Now it's
simple. Import is what you use to get schema definitions from another
namespace (I.e. different from the targetNamespace being defined by the
importing document.) Include is what you use when you've spread the
definition of one particular namespace across multiple schema documents.
There are some other subtle semantic differences, and some slightly
different rules for error reporting in the case a reference doesn't
resolve, but those in no way affect your choice of which to use: include
for the same namespace, import for others. Design your language first,
then write the schema documents that capture your design. If there lots
of elements or types in one namespace, or if lots of people are working on
separate parts of the definition, you can split the schema for that large
namespace into multiple documents, and use include to pull the pieces
together.
Good luck, I hope this helps!
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]