RE: [ubl-ndrsc] ur-schema necessitates xsi:type everywhere in ins tance

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

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.