RE: [ubl-ndrsc] [Fwd: FW: [oagis-users] UserArea Extensions for Version 8.0]

[Matthew Gertner <matthew.gertner@schemantix.com>]

<polemic>
I've always thought that open content models are a crutch to avoid difficult
design decisions. With correct information modeling, it shouldn't be such a
big problem to include information from other namespaces into a document.
However, there should be some commonly understood base semantics referenced
in the core document and not just a wooly "any" tag (purposesly using gobs
of loaded terms).

In other words, say we have a "unit" tag somewhere in UBL, and we want to be
able to stick in other vocabularies that represent units of measure. Either
we should find out if there is an appropriate base type for this (unlikely),
or define our own and mandate that other vocabularies should be adapted
accordingly. After all, this is supposed to be a *universal* business
language. Admittedly, this will be a challenge and it will take time for
people to adapt, but this is why we have a Liaison SC working hard on
coordinating with other groups. Just sticking in a bunch of "any" tags to
make the vocabularies entirely flexible totally contradicts the idea of
defining schemas for valid documents in the first place.
</polemic>

Matt

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Thursday, May 30, 2002 12:15 AM
> To: Burcham, Bill
> Cc: ubl-ndrsc@lists.oasis-open.org
> Subject: Re: [ubl-ndrsc] [Fwd: FW: [oagis-users] UserArea 
> Extensions for
> V ersion 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/GoodSprous
e.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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>