[
Lists Home |
Date Index |
Thread Index
]
On the subject of context: There is an emerging OASIS standard called
"Content Assembly Mechanism" (CAM [1]). In short, it enables a run-time
binding of context. It is in its infancy, but when released will enable
(business process) context to be applied to a "generic" schema and XML
document instances to be produced that reflect the proper context for
various parts of the XML document instances.
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
[1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cam
Sean McGrath wrote:
>
> (I'm playing catch-up on the list. Apologies).
>
> [Chiusano Joseph]
> >Here are several off the top of my head:
> >(1) "feet":
> > - One occurrence could be a string that contains the anatomical
> >condition of a foot, perhaps in a list of body parts in a doctor's form;
> >- Another occurrence could be a distance;
>
> Hello Joseph. The start of this post is a response to your e-mail
> but the rest of it is a rant against namespaces. Its not a rant
> against your post!
>
> As for the example of different occurrences of "feed".
>
> One word:
> CONTEXT
>
> The element structure of XML is a simple, elegant way of
> contextualising chunks of text. XPath etc. give you techniques for
> interacting with that context.
>
> The element context of XML is all you need to resolve the multiple
> occurrences of "feet" elements in your example.
>
> As far as XML tools are concerned, where is the "collission"?
> Does the collisson stop a WF parser checking well-formedmess? No.
> Does it stop an XPATH processor winding its way through
> the nodes? No.
>
> If you need to distinguish one element from another - regardless of
> whether or not they share the same element type
> name - you can use the element *context* to do so.
>
> The element structure gives you all the context machinery you
> need. Namespaces simple adds more context machinery. As
> pointless as it is complex.
>
> The extra context machinery is unnecessary and extremely
> counterproductive. It adds complexity in-your-face all
> the way through XML application development and
> XML interchange.
>
> Anybody who thinks this is not the case has a much better way of
> writing XML applications than I have (and is keeping the details to
> themselves to boot :-).
>
> Name collision lower down than application-level semantics is a myth.
>
> At the application level, you have the full power of the element
> context model to handle it.
>
> If you need to differentiate elements for interchange purposes, interchange
> XPaths along with the instance. What's the problem?
>
> Adding another context model - a complex context model at that - from
> the UnicodeWithAngleBrackets, right the way up to the application,
> is a really, really bad idea.
>
> Its also another dreadful example of more and more *stuff* being piled
> into XML without any apparent thought for how functionality can
> be modularised, pipelined and otherwise kept from exploding in our
> faces in one big fireball of complexity.
>
> The alternative to namespaces? XML + XPath.
>
> Why not? Lets explore it.
>
> All around me I see SAXes, XPaths, DOMs etc. etc. that
> are infested with namespace complexity.
>
> I see programmers all over the map pulling tufts of their own hair out.
> Programmers who strongly suspect that, in this case, the XML appointed
> emperor has no clothes, but are reticent to come forward and say so.
>
> There simply must be a better way.
>
> Sean
> http://seanmcgrath.blogspot.com
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
