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 markupanddata

Well, then I take back what I said about disagreeing with you; we
actually seem to be agreed on every point below, so it seems like I just
misinterpreted what you were saying previously.  Sorry! :-)

Doug Glidden
Software Engineer
The Boeing Company
Douglass.A.Glidden@boeing.com

-----Original Message-----
From: Amelia A Lewis [mailto:amyzing@talsever.com] 
Sent: Tuesday, August 11, 2009 18:35
To: Glidden, Douglass A
Cc: costello@mitre.org; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Lesson Learned: Use namespaces for both
markupanddata

Douglass,

I'm afraid that we may be talking somewhat at cross-purposes.

On Tue, 11 Aug 2009 17:44:19 -0400, Glidden, Douglass A wrote:
> In processing a large XML document, the cost of keeping track of the 
> prefix-to-namespace mappings is fairly trivial (mid-stream 
> redefinitions

True for structure.  Not true for content (because even if you know that
the content may hold a QName, you don't know which mappings are
significant, unless your parser actually looks at the content--at which
point it's an application).

> The only time I can think of when the prefix mappings become 
> non-trivial (and the one you seem to be alluding to when you talk
about "copying"
> and "pasting") is when doing manual editing of raw XML data, which 
> _should_ be a fringe case.

Any concatenation of fragments from arbitrary source locations (cf. 
XSLT document() function) has this issue.  Also true of XML APIs.  It
isn't done very often--in part because QNames in content make it
unsafe/unreliable.

> <example xmlns:aqr="http://www.aquarium.org";
> xmlns:atl="http://www.artillery.gov";>
>   <aqr:tank>
>     <aqr:capacity>55</aqr:capacity>
>   </aqr:tank>
>   <atl:tank>
>     <atl:capacity>300</atl:capacity>
>   </atl:tank>
> </example>

This is where we're at cross-purposes.  This has no QNames in content.  
It has QNames in structure.  This is an example of good design.  The
following:

> <example ...>
>   <tank xsi:type="Aquarium">
>     <capacity>55</capacity>
>   </tank>
>   <tank xsi:type="Artillery">
>     <capacity>300</capacity>
>   </tank>
> </example>

Also has no QNames in content.  I think it's horrid design, but then, I
have Bad Things To Say(tm) about XML Schema, too.

This:

<example xmlns:doom="http://www.nuke.them.from.orbit"; 
xmlns:a="http://www.aquarium.org";>
  <object>
    <name>a:tank</name>
    <capacity>a:55</capacity>
  </object>
  <object>
    <name>doom:tank</name>
    <capacity>doom:300</capacity>
  </object>
</example>

Is perhaps closer to Roger's recommendation, and may also illustrate
some of the problems.  I mean, if you're going to use QNames in content,
why not encode the units as well?  Well, sort of encode the units; after
all, <range>doom:40</range> has the obvious meaning of ... 
uh ...

Oh, yeah.  Bind "doom" to "http://www.aquarium.org";, and
<range>doom:40</range> means 40th parallel of latitude.  *Obviously*.

> I definitely don't agree with Roger's idea of using QNames in data, 
> either, though-IMHO that dangerously mixes metadata with data.

This was really what the discussion was on about.  Your initial example
is not "QNames in content", it's "good XML design with namespaces".

:-)

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
  "You go on.  You just go on.  There's nothing more to it, and there's
no trick to make it easier.  You just go on."
  "What do you find on the other side?  When you go on?"
  She shrugged.  "Your life again.  What else?"
		-- Harra Csurik and Miles Vorkosigan


[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