OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XIN: XML implicit namespace definitions

On 24 Mar 2009, at 10:08 , Liam Quin wrote:

 > I've been thinking for a while about this proposal.
 > ...
 > Consider for a moment an XHTML document that uses SVG, MathML
 > and XForms.  And for SVg we need XLink too.

 > <xhtml
 >   xmlns="http://www.w3.org/1999/xhtml";
 >   xmlns:svg="http://www.w3.org/2000/svg";
 >   xmlns:m="http://www.w3.org/1998/Math/MathML";
 >   xmlns:xlink="http://www.w3.org/1999/xlink";
 >   xmlns:xforms="http://www.w3.org/2002/xforms";>

 > That's a lot to remember, so people use copy and paste, and
 > before long you get other namespace declarations in there too.

 > In practice, though, almost all elements here are going to be
 > unambiguous if you take their ancestors into account, and
 > attributes too.

 > Imagine having an XML vocabulary (or some other mechanism) that
 > says, in this context, the following elements are in the
 > following namespace, and in this other context, the following
 > elements and attributes are in this other namespace, and so on.

Well, as David Carlisle and Eric van der Vlist have pointed out,
we do have another mechanism that can do this.  The namespaces
spec provides for namespace attributes to be defaultable just for
this reason.

 > The main benefits you get are
 > (1) your XML documents are simpler and smaller
 > (2) it's easier to remember the xin file than a mass of URIs
 > (3) you dereference xin files and cache them -- they are not
 >  names -- so whether there is a trailing slash or not, whether
 >  there's a # at the end, whether characters are escaped or not,
 >  makes no difference, an architectural improvement.

I think these are much the same advantages as for putting the
namespace declarations in the DTD.

 > A secondary downside is that when you rely on something not
 > ubiquitous, you risk losing some interoperability.

And this is much the same problem as using the DTD.

If your sense is that a new proposal is needed, I assume it's
because you don't feel the DTD-based solution has worked out well
in practice.  If it hasn't worked out well, I guess it's because
so many users use XML parsers which don't consult the external
DTD subset and work properly only for stand-alone documents.

The question that comes to my mind, as I look at this proposal,
is: What will make software more willing to consult an external
XIN document than to consult an external DTD subset?  What will
make users more willing to insist that the parsers they use
respect the XIN conventions than they are to insist that their
software, whether validating or not, consult the external DTD

If you have persuasive answers to those questions, the proposal
has a chance.  Otherwise, ...


* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS