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 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