OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC