OASIS Open Mailing List Archives  ·  All Lists  ·  ubl-ndrsc  ·  2002-05

ubl-ndrsc — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

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

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]