MHonArc v2.5.2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ubl-ndrsc] [Fwd: FW: [oagis-users] UserArea Extensions for Version 8.0]
From: "Eve L. Maler" <>
To: "Burcham, Bill" <>
Date: Wed, 29 May 2002 18:14:59 -0400
Sorry about putting so much value judgment into my previous post...
When the "open content model" design still existed in that early draft
of XSD, I was wary because all my previous experience taught me to favor
tight validation, but observed that it gave the cleanest way of
achieving what you're talking about. Now we don't have this tool
available to us, and we have to make our models pretty hairy (bristling
with <any>) to accomplish the same thing. But if we like all of its
other effects, maybe the hairiness is worth it.
I'm not saying I buy it yet, you understand, but I'm trying to keep a
more open mind. :-)
Eve
Burcham, Bill wrote:
> "junk" is such a loaded term Eve :-) I believe that if you take XML
> Namespaces to heart then you arrive at a model where it's perfectly
> reasonable to allow elements of unforeseen namespaces to ride along in
> UBL instance documents. Just because in the textual view of the
> document, elements from non-UBL namespaces are visible, that doesn't
> mean they need be visible to UBL-centric processing logic. In the
> infoset, each node is part of a namespace right? If you're processing
> UBL nodes, you're not even going to notice non-UBL ones.
>
> To Jessica Glace's point about open content being useful early in a
> schema's lifecycle... I think you've done a great job of capturing the
> common wisdom, but I don't see it that way. Yeah, if the reason for
> using open content were to allow flexibility during schema development
> then I'd be against it too. The reason for open content is not
> "flexibility" really -- it's "composability" (is that a word ?!?). The
> point of open content is that after UBL is "in the can" someone comes
> along with a really cool vocabulary like, oh, say the Dublin Core
> <http://dublincore.org/>, or say some vocabulary that would let you
> track the provenance
> <http://www.ldc.upenn.edu/exploration/expl2000/papers/goodsprouse/GoodSprouse.html>some
> element, or any of the myriad kinds of markup that haven't even been
> developed yet; and an open content model would allow a valid UBL
> document instance to carry that unforeseen markup. We wouldn't
> sacrafice any clarity or precision as far as our domain is concerned ...
> we'd just be providing the plug points for completely orthogonal domains
> -- that's the whole /point/ of namespaces isn't it?
>
> Doesn't it seem a bit heavy-handed to dictate the complete structure of
> an instance document when we've got the nifty namespace mechanism
> ready-made for the purpose of cleanly separating concerns. Wouldn't it
> be more neighborly to define a namespace that can coexist with others?
>
> -Bill
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com
