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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Re: URIs, concrete

[ Lists Home | Date Index | Thread Index ]


Greetings,

On Thu, 1 Aug 2002, Simon St.Laurent wrote:

> Norman Gray writes:
> > So it isn't quite headlined, and it may or may not be a design wart,
> > but there's no way you can say it's ambiguous or implicit.
>
> I'm not saying that the specification is ambiguous.  I'm saying that the
> ambiguous position in which it leaves attributes is wrong.

I see what you mean.  You talk later of `the list of things about
which developers must agree', and if you see, in some instance you
receive, a default namespace and an unprefixed attribute, then you
don't in practice know whether the entity which generated the instance
has read section 5.2 carefully enough, so it's ambiguous what they
_meant_, since there are two things they might have meant, with
unfortunately equal probability.  No problem.

Excluding unprefixed attributes from the default namespace is something
that the spec does carefully and explicitly -- it's clearly not an
accidental omission.  This suggests that the authors had some specific
case in mind, or a processing imperative.  There are no rationales
included in the text -- is anyone aware of a rationale floated at
the time?

Hmm, in the example (David's?)

  <html:img src="t.gif">

you can see a justification for deeming `src' to be in the html:
namespace, or in the default one, but you'd never guess that it would be
in no namespace.  I can imagine that there was a long argument about which
it should be, resolved in this case by choosing the oddest alternative.
If that's the case, it more-or-less blesses a heuristic such as Simon is
suggesting, as it's so evasive that it's tantamount to `implementation
defined' without actually using those words.

> The "so what?" emerges from the years of debate about what this
> specification's implications for document interchange are.  In theory,
> Namespaces in XML was supposed to make it easier to exchange information
> written using a more explicit namespacing approach.  In practice, it's
> merely added to the list of things about which developers must agree,
> something I thought XML was about reducing.  (Removing the SGML
> declaration and all that...)
>
> As for the heat, I think four years of continuous problems with
> Namespaces in XML being dismissed as non-problems is more than enough.
> At this point I think it's time to bang on the walls - polite discussion
> has gained us pretty much nothing.

Oh, I hope I wasn't airily dismissing things as non-problems.  I
fail to get the problems you'd mentioned (`developers get confused!';
`well they should RTFS!'), but I do get the point of `the list of
things about which developers must agree'.

Is it really too late to change this one sentence in section 5.2 to one
of the more natural alternatives?  There seems to be little opposition to
the suggestion that the sentence is defective.  Cases like the html:img
one above work because the processors for those cases are in practice
treating unprefixed-attribute behaviour as implementation defined,
so they wouldn't become any more broken if the spec were altered.

All the best,

Norman


-- 
---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     norman@astro.gla.ac.uk





 

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

Copyright 2001 XML.org. This site is hosted by OASIS