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]


"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, or say some vocabulary that would let you track the provenance 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

-----Original Message-----
From: Eve L. Maler [
mailto:eve.maler@sun.com]
Sent: Wednesday, May 29, 2002 3:53 PM
To: Burcham, Bill
Cc: ubl-ndrsc@lists.oasis-open.org
Subject: Re: [ubl-ndrsc] [Fwd: FW: [oagis-users] UserArea Extensions for
Version 8.0]


I would be concerned about putting wildcards everywhere.  It would mean
that the vanilla UBL library would allow all kinds of junk, and XSD
validation would mean little.  But there may be locations where we want
to use it strategically.  (Eventually we'll need a rule about wildcard
usage anyway...)

        Eve

Burcham, Bill wrote:
> When I look at that BOD extension example (below) I see an "open
> content" model (as described by Roger Costello in this ancient
> correspondence
> <
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0159.html>and
> in part three of his eggcelent XML Schema Tutorial
> <
http://www.xfront.com/xml-schema.html>).  I think UBL should define an
> open content model, i.e. just about everywhere in a valid UBL document
> instance, it should be easy to hang elements from non-UBL namespaces.  
> What do you think?
>
> -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