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] ur-schema necessitates xsi:type everywhere in ins tance


Will someone please alter my specific example as Matt describes and post it
back to the list?  I think it's important to see a concrete, valid example.

-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz] 
Sent: Wednesday, February 05, 2003 9:07 AM
To: Burcham, Bill; Lisa-Aeon; UBL-NDR
Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in
instance


Yes, the cascading problem is there, and I don't see any way around it. You
have to pay somewhere...

Assuming this accurately represents the decision of the NDRSC (perhaps a big
assumption), your examples should be correct if all xsi:type attributes
except the one pointing to the p3 namespace are removed, no?

> -----Original Message-----
> From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
> Sent: Wednesday, February 05, 2003 3:57 PM
> To: 'Matthew Gertner'; Lisa-Aeon; UBL-NDR
> Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in 
> instance
> 
> If I understand you, then for instance, if a user needed to eliminate
zip
> code from an Address (assuming that Zip code was "required") then that 
> user is going to suddenly be using ur-schemas for all the doc-types 
> that
use
> Address.  This is the "cascade" effect we talked about in Barcelona.
> 
> I don't have a solution to this problem -- I just want to be sure
we're
> all
> aware of it.
> 
> For those who haven't read the example: it defines an ur-schema with a
few
> types, one of which, CountryCode has a Code element.  The "UBL" schema
is
> derived from that one (by _restriction_) and makes some of the
elements
> required (they're all optional in the ur-schema by definition).  I
then
> define a "third-party" schema that derives from the ur-schema and
changes
> CountryCode so as to replace the Code element with an element called 
> "NewElement".  Two instances are provided: a vanilla UBL one and a 
> "third-party" one.
> 
> In my original message (the one Matt just replied to) I provided an 
> example of the ur-proposal as I understood it -- and it required 
> xsi:type everywhere.  Matt: will you please correct my example and 
> post it back
to
> the list.
> 
> 
> -----Original Message-----
> From: Matthew Gertner [mailto:matthew.gertner@acepoint.cz]
> Sent: Wednesday, February 05, 2003 8:45 AM
> To: Burcham, Bill; Lisa-Aeon; UBL-NDR
> Subject: RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in 
> instance
> 
> 
> This isn't my understanding, or at least it is only one possible 
> interpretation. I would take it as a given that it is unacceptable to 
> require xsi:type on every element. This is hardly likely to encourage 
> adoption of UBL.
> 
> Hence, UBL document types should reference UBL types/element in their 
> content models. If you want to use the ur-type of a type, you need to
use
> the ur-type of the document type as well. In this way you put the onus
on
> the ur-type users, which seems appropriate since they are likely to be
the
> minority.
> 
> Matt
> 
> -----Original Message-----
> From: Burcham, Bill [mailto:Bill_Burcham@stercomm.com]
> Sent: Wednesday, February 05, 2003 3:40 PM
> To: 'Lisa-Aeon'; UBL-NDR
> Subject: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in 
> instance
> 
> One issue with ur-proposal that was not discussed was this issue (from
a
> private message I produced on Monday -- also, see the attachment):
> 
> ... I worked out a little example of the ur-type proposal a while
back. I
> think I've forwarded it before, but to save you groveling about the
list
> I've attached it again. I've made a namespace for ur-types and a
dervied
> one
> for "UBL types". Then I made a third for a "third-party-restriction".
A
> key
> issue we identified with Paella is as far as I can tell, still an
issue
> with
> the latest ur-type proposal. If you look at a "vanilla" UBL instance 
> document (ubl-doc.xml) you see it has to use xsi:type on every
element.
> The
> same holds for a "customized" UBL instance document 
> (third-party-restriction-doc.xml).
> The reason this happens is that every element declaration must be of
an
> ur-type -- never a (derived) UBL type, or a (derived) customized type.
It
> must be so since this is the means by which we are able, after the
fact,
> to
> derive from the ur-type without the horrendous "cascade" back through
all
> the referenceing content models (and the ones that reference those,
and so
> on -- remember Barcelona). The fact that the instance documents must
carry
> xsi:type everywhere means that schema validation is _not_ (on its own) 
> enforcing a particular vocabulary -- I can really use an ur-type
wherever
> I
> want to and the schema validator isn't going to squawk.
> If that's the case, then what, exactly is the value of the UBL
namespace
> (i.e. the non-ur-types)? I mean, should we just ship the "everything
is
> optional" ur-types and be done? Maybe I misunderstand the proposal. If
so,
> could someone please correct my simple example and show me some new 
> instance documents that don't require xsi:type everywhere? Barring 
> that we
should
> probably revisit our discussion from last March and decide whether
that's
> ok, or whether we need to fix it somehow (and no, I don't have any
ideas
> just now :-) One thing I have tried is to get the xsi:type attributes
on
> the
> elements in ubl.xsd to _default_ to the UBL types somehow... But I
fear I
> am
> not nearly the XSD wizard for that task -- heck I can hardly even
describe
> it.
> 


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


Powered by eList eXpress LLC