[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Lesson Learned: Use namespaces for both markup and data
- From: "Jim Tivy" <jimt@bluestream.com>
- To: "'Amelia A Lewis'" <amyzing@talsever.com>,"'Costello, Roger L.'" <costello@mitre.org>
- Date: Tue, 11 Aug 2009 15:02:35 -0700
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]