RE: [xml-dev] Lesson Learned: Use namespaces for both markup anddata

[Amelia A Lewis <amyzing@talsever.com>]

On Tue, 11 Aug 2009 15:46:53 -0400, Costello, Roger L. wrote:
>> If there's any chance of the information 
>> being removed from context, the QNames 
>> can turn into garbage.
> 
>> you're introducing an indirect dependency 
>> on the structure of the document in which 
>> the data is contained.  When you go to grab 
>> it, you'd better hope you grab all the 
>> necessary bits of context.
> 
> Isn't that true with any data? 

No.

> The following example is not using a QName:
> 
> <aquarium>tank</aquarium>

Sorry, is this a:aquarium or b:aquarium?  Is "tank" a qualified name?

> If I take the data out of context I get this:
> 
>     tank
> 
> Out of context I don't know if it's:
> 
>    - an artillery tank
>    - an aquarium tank
>    - an oil tank

And here, the context is one element.  Given that you're processing the 
element, I think you can probably afford it.

> Conversely, if I use a QName:
> 
> <Example xmlns:aquarium="http://www.aquarium.org";>
>     <Object>aquarium:tank</Object>
> </Example>
> 
> and take the data out of context I get this:
> 
>     aquarium:tank
> 
> This appears to be richer.

How?

<Example xmlns:artillery="http://www.aquarium.org";>
    <Object>artillery:tank</Object>
</Example>

<ex:Example xmlns="http://www.aquarium.org";>
    <ex:Object>tank</ex:Object>
</ex:Example>

Not buying it.  You're investing meaning in prefixes, which the 
specification says shouldn't carry meaning.

> Isn't understanding always dependent on context?

It's a question of the extent of context.

If your above example is buried in a 100MB file, and the xmlns:aquarium 
definition is 40MB away ... that's a *hell* of a lot of context to hold 
in order to actually map the prefix back to the namespace identifier.

And as soon as you start placing meaning on prefixes (like the 
*extremely long* prefix "aquarium"), you're inviting all sorts of 
interesting attacks on your data stream (not to mention that naive 
implementors of XML-based protocols are apt to hard-code prefixes, and 
not handle unknown ones) (early jabber/xmlpp servers, for instance, 
were prone to this, which meant that custom clients had to hard-code as 
well, and the rot had a tendency to spread, although it was eventually 
addressed, as the protocol matured and the developers learned that 
prefixes didn't matter).

>> By allowing QNames to be part of content, 
>> information that *ought* to have been restricted 
>> to the processor/parser is instead exposed to 
>> the application.
> 
> Doesn't the namespace in a QName give an application useful 
> information? For example, 

Not part of my argument.

According to the namespaces specification, *only* the namespace 
identifier carries information, but in a QName, it isn't present, it's 
avaialble only by resolving that prefix, in context, to the mapped 
identifier.

>     {http://www.aquarium.org}tank
> 
> Isn't the namespace in this QName useful to an application?

That isn't a QName.  I agree entirely, that's *vastly* more useful than 
a QName would be.  Although I think you'd be still better off with: 
http://www.aquarium.org/identifiers/objects/tank.  Or simply 
http://www.aquarium.org?tank, perhaps.  But what you're presenting is 
James Clark notation for an expanded name.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
Do you ever feel like putting your fist through a window just so you
can feel something?