OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] Discussion of substitution groups


[ubl] Discussion of substitution groupsI've been trying the redefine
mechanism with
UBL, partly using the examples others have
posted to the various lists, none of which I've
found to work in up-to-date mainstream tools.

The problem I keep getting seems to be
exactly that described by way of a warning
in the XSD spec

http://www.w3.org/TR/xmlschema-0/#Redefine

"Our example has been carefully constructed
so that the redefined Address type does not
conflict in any way with the types that are
derived from the original Address definition.
But note that it would be very easy to create
a conflict. For example, if the international
address type derivations had extended
Address by adding a country element, then
the redefinition of Address would be adding
an element of the same name to the content
model of Address. It is illegal to have two
elements of the same name (and in the same
target namespace) but different types in a
content model, and so the attempt to redefine
Address would cause an error. In general,
redefine does not protect you from such
errors, and it should be used cautiously. "

This all the more persuades me that for
minor versioning and codelists we have
only one sensible option - substitution
groups (without use of abstracts).

All the best

Steve




----- Original Message ----- 
From: Stephen Green
To: ubl@lists.oasis-open.org
Sent: Monday, July 18, 2005 12:05 PM
Subject: Re: [ubl] Discussion of substitution groups


Just some additional comments:

I did find that the main development problem
getting substitution group (sg) to work happens
when you miss either an import in a document
schema or the corresponding namespace in
the instance. This problem seems to be due to
the fact that a document schema without all
the necessary imports can still be valid. If you
don't have a derived CAC imported into the
Document schema it is valid but the instance
won't be able to use the CAC's substitutions if
1. the derived CAC isn't imported into the
     document schema
or 2. the instance doesn't include the derived
CAC's namespace.

Otherwise it is all straightforward in
development provided you have the right tools.

On the matter of tools though I did find there
are still some problems with using the sg's:
even a few up to date mainstream tools still fail
 to validate some valid schemas which use the
 sg's.
I general the latest versions of tools are better
 but not all of them are OK yet.

I note the urls sent by Ken a few days ago show
that there are experts who think sg's have better
support than redefine.

Regarding redefine though, I don't think anyone
has yet shown that it can be used in the UBL
schema architecture for either codelists or
general minor versionng. Sg's can plainly be used
though, so I think it is pretty much a no-brainer -
unless we decide against having any minor
versions at all for UBL. Without any minor versions
though we might be making it very expensive for
adopters to keep their implementations up to date
with updated versions of UBL. At the same time
we might be causing fragmentation of the
implementations if, by the lack of minor versions
which are polymorphic, we cause it to be cheaper
to customise than to adopt future versions of UBL.

All the best

Steve



----- Original Message ----- 
From: Stephen Green
To: ubl@lists.oasis-open.org
Sent: Monday, July 18, 2005 11:18 AM
Subject: Re: [ubl] Discussion of substitution groups


Folks,

As we are looking at substitution groups in
advance of the codelist discussion (though
leading into it of course) I thought I'll need
to jump the gun a bit on prototyping I adapted
from some work I've been doing with Marty
(based on his prototypes for codelist extension).

It uses the latest UBL 2.0 draft schemas
sent by David over the last few days.
It demonstrates both

1. Marty's codelist mechanism which now
uses substitution groups * without abstracts *
(personally I'm all for that following the work
we did with Arofan, though I still dislike the
abstract element/type method)

2. Arofan's general minor versioning
(and customisation) mechanism which we
worked on in the working team in April.

Notably, using the latest schemas is
rather more satisfying and assuring in
that it shows there to be no development
problem at all in using the substitution
group / global elements / global types
(without abstracts) / derivation mechanism
with our current 2.0 schemas to produce
a * hypothetical * 2.1 set of extended minor
version schemas (both BIEs and codelists
extended).

The attached file can be saved with extension
.zip then unzipped.

All the best

Steve



----- Original Message ----- 
From: CRAWFORD, Mark
To: ubl@lists.oasis-open.org
Sent: Monday, July 18, 2005 1:41 AM
Subject: RE: [ubl] Discussion of substitution groups


>Remember that we are discussing substitution groups (and possible
>alternatives to the same) as a code list extension mechanism in
>next week's Atlantic TC call.  Given that Mark Crawford will be
>unable to attend, it would be good to have as much information as
>possible (including the outcome of discussions with Henry
>Thompson) posted to this list prior to that meeting, preferably at
>the beginning of the week.

Remember that our discussions on the use of substitution groups within our
UBL NDR needs to focus on what our requirements are for developing UBL
normative schema from our models for vote by the TC - to include UBL
developed code lists.  Customizer requirements are left to the extension
methodology.

Mark
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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