W3C home > Mailing lists > Public > www-tag@w3.org > September 2003

Action: Redraft 4.10.2 to include some good practice notes

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Wed, 03 Sep 2003 13:43:32 -0400
To: www-tag@w3.org
Message-ID: <87d6ehahtn.fsf@nwalsh.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is my suggested replacement for the text in 4.10.2, with change bars.

  The authority responsible for "weather.example.com" realize that they
  can provide more interesting representations by creating instances
| that consist of elements defined in different XML-based
  formats, such as XHTML, SVG, and MathML. How do the application
  designers ensure that there are no naming conflicts when they combine
  elements from different formats (e.g., suppose that the "p" element is
  defined in two or more combined XML formats)? "Namespaces in XML"
  [XMLNS] provides a mechanism for establishing a globally unique name
  that can be understood in any context.

| The "fully qualified" form of an XML element or attribute name is the
  combination of its namespace URI and its local name. This is
  represented lexically in documents by associating namespace names with
  (optional) prefixes and combining prefixes and local names with a
  colon as described in "Namespaces in XML."

  Format specification designers that declare namespaces thus provide a
  global context for instances of the data format. Establishing this
  global context allows those instances (and portions thereof) to be
  re-used and combined in novel ways not yet imagined. Failure to
  provide a namespace makes such re-use more difficult, perhaps
  impractical in some cases.

|   Good practice: Use Namespaces: Format specifications that create
|     new XML vocabularies SHOULD place all element names and global
|     attribute names in a namespace.
|
| Attributes are always scoped by the element on which they appear. In
| that respect they are a somewhat special case. An attribute that is
| "global", that is, one that might meaningfully appear on a great many
| elements, including elements in other namespaces, should be explicitly
| placed in a namespace. Local attributes, ones associated with only a
| particular element, need not be namespaced since their meaning will
| always be clear from the context provided by that element.
|
| The type attribute from W3C XML Schema is an example of a global
| attribute. It can be used by authors of any vocabulary to assert
| something about the type of the element on which it appears. The type
| attribute occurs in the W3C XML Schema namespace and must always be
| fully qualified. The frame attribute on an HTML table is an example of
| a local attribute. There's no value in placing that attribute in a
| namespace as it will never be useful to place it on an element other
| than an HTML table.

  The most significant technical drawback to using namespaces is that
  they do not interact well with DTDs. DTDs perform validation based on
  the lexical form of the name, making prefixes semantically significant
  in ways that are not desirable. As other schema technologies become
  widely deployed, this drawback will diminish in significance.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | If you want to build a ship, don't drum up
XML Standards Architect | the men to gather wood, divide the work and
Web Tech. and Standards | give orders. Instead, teach them to yearn for
Sun Microsystems, Inc.  | the vast and endless sea.--A. de Saint-Exupery
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/VihDOyltUcwYWjsRAk+oAJ0Qv5RHS55MesES+PX7RIJimhcobwCgqBLB
d4EQkRt8fWH1YtrQHLrlL8Q=
=bKc8
-----END PGP SIGNATURE-----
Received on Wednesday, 3 September 2003 13:46:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:20 GMT