XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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] Lesson Learned: Use namespaces for both markup anddata

 
Thanks Rich and Amy! I have a few questions.

Amy, you 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? 

The following example is not using a QName:

<aquarium>tank</aquarium>

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 so forth.

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.

Isn't understanding always dependent on context?

> 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, 

    {http://www.aquarium.org}tank

Isn't the namespace in this QName useful to an application?

Thanks Rich for pointing me to: http://www.w3.org/2001/tag/doc/qnameids

I read it and am embarrassed to say that I still don't see the problem with QName. This paragraph seems to be important:

> Using a QName as a shortcut for a {URI, local-name} 
> pair is often convenient, but it carries a price. 
> In order to identify QNames in content, a processor 
> must understand the syntax and possibly the semantics 
> of the content. The "x:p" in the preceding example can 
> only be recognized as a QName by a processor that 
> understands both XPath (in order to parse the attribute 
> value) and XSLT (in order to know which attributes 
> contain XPath expressions).

What is the paragraph saying? What price is it identifying?

/Roger



    

-----Original Message-----
From: Amelia A Lewis [mailto:amyzing@talsever.com] 
Sent: Tuesday, August 11, 2009 2:56 PM
To: Costello, Roger L.
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] Lesson Learned: Use namespaces for both markup and data

On Tue, 11 Aug 2009 14:40:39 -0400, Costello, Roger L. wrote:
>> Things get nasty when people start using QNames for everything
> How do things get nasty? What is the technical problem with QNames?

Resolving prefixes.

If there's any chance of the information being removed from context, 
the QNames can turn into garbage.

If you compare the QNames a:data and b:data, are they the same?  If you 
compare the QNames a:data and a:data are they the same?  What about 
data and data (default prefix)?

So, instead of keeping your data localized, by introducing QNames in 
context, 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.

So what does it win you?  Shorter names (well, and URIs typically 
contain characters illegal in NAME, NCName, NMTOKEN--that's a good 
reason to have not chosen URIs, but it's too late for that).

Prefix bindings (particularly the default prefix, "") may change within 
the scope of a single document (most people won't change the 
non-default prefix, but there are reasons to do it, such as 
concatenating multiple documents together, when you know that there may 
be QNames in content).  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.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
But pain ... seems to me an insufficient reason not to embrace life.  
Being dead is quite painless.  Pain, like time, is going to come on 
regardless.  Question is, what glorious moments can you win from life 
in addition to the pain?
   -- Cordelia Naismith Vorkosigan [Lois McMasters Bujold, "Barrayar"]


[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