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 and data

Agreed

Attaching a value space to every piece of content on earth would be very
bothersome or should I say en:bothersome.

Context is important and context holds the type information.

Exceptions, however, arise when your data is a programming language that
addresses XML content items - such as XPath in XSLT attributes.

Jim

-----Original Message-----
From: Amelia A Lewis [mailto:amyzing@talsever.com] 
Sent: Tuesday, August 11, 2009 1:35 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 16:06:05 -0400, Costello, Roger L. wrote:
>    When this QName value is taken out of context, 
>    it does not have less information than a 
>    non-QName value taken out of context.

True enough, if you strip all context.

You're expected to maintain the context of the element or attribute 
when interpreting any data in an XML document.  If you aren't doing 
that, why use XML?  CSV is much more compact.

So, you have a labelled graph, and each information-bearing node has a 
label.  You may want to look a little way up the ancestor axis (for 
instance, you may want to know what element an attribute is on before 
interpreting the content of the attribute).  Or you may not, but ... if 
you're relying on that context, chances are good that you have a 
schema.  The information content of a particular node is relatively 
well-localized; it may need no more than it's label (element or 
attribute name), or it may need slightly more information extracted 
from the ancestor axis, but the structure of XML imposes the rules, 
reasonably cleanly.  You can cut a fragment 
(<example><object>value</object></example>) and--based on the 
namespaces required by the *structure* (example and object, here), 
paste it into some other XML safely (FSVO "safely").

Once you have namespaces in content, then you're pretty much forced to 
copy *all* in-scope namespaces for the example fragment, because you 
can't tell which ones you need.

Your application is also forced to replicate the functionality of an 
XML processor.  It must keep track not only of the expanded names of 
the elements/attributes that it processes, but also the 
prefix-to-identifier mappings that are in force for that document.

"aquarium:tank" may equal "artillery:tank" or "tank", each of these 
QNames binding their prefixes to the same namespace identifier.  Stick 
QNames in context and you then have to explain, to the application 
processors, that in this case, an artillery:tank is *just the same* as 
an aquarium:tank, because they're both bound to the 
http://www.gaz-guzzlers.com URI.  Application developers will, with 
perfect reason, wish to beat you, and the first person who put QNames 
in content, and probably the authors of the namespaces in XML spec.

Poor locality of data, information not enforced implicitly by the rules 
of the XML schema, and a data representation that misleadingly does not 
contain half of the significant information (assuming the local name 
carries half the value, a QName does not provide the other half, it 
provides a pointer that allows you to look that up, so long as you 
maintain the complete state at the point of parsing).

QNames in content are a *terrible* idea.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
Confidence: a feeling peculiar to the stage just before full
comprehension of the problem.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php





[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