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

Title: Re: [ubl] Discussion of substitution groups

I guess I expect that, with the design you are
articulating, the schema filename might not have
the minor version as a mandatory inclusion.
Also, if this same-namespace minor version
design were adopted, so that software receives
newer versions obliviously, to take advantage
of this feature you'd want to call a schema minor
'upgrade' by the same file name as the previous
schema. There might not be much point keeping
the 'space' name (namespace) but changing the
filename, would there?
The schemaLocation is vague because it can
be relative so you could make the schema
minor version distinction by giving the schemas
the same name but storing them in different
absolute locations (a sort of external polymorphism
without the audit trail). The relative location in the
instance could be such that a different schema is
pointed to depending on the location of the
instance or some kind of caching, etc (which
could change anyway as technology changes).
That's what I mean by vague.
In short I wouldn't be so happy about trading
under such an 'standard' architecture. Nor,
I think, would my auditors or tax authority!
(I'm not seeking to speak for these but just
anticipating likely objections later which could
hinder UBL adoption drastically.) I'd think there
would be the addition of substantial ambuiguity
by relying solely on the schemaLocation and
schema filename rather than the namespace.
In particular: The following doesn't look too good -
the trading agreement gives the schema filename
rather than the namespace (as normative). ??
That's what you get if you defer the minor
version name to the filename but leave it out
of the namespace.
All the best
----- Original Message -----
Sent: Wednesday, July 20, 2005 3:39 PM
Subject: Re: [ubl] Discussion of substitution groups

Since the schema location is versioned, not sure why you keep referring to it as vague.
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee and OASIS Representative,
Vice Chair - OASIS UBL TC
Vice Chair - UN/CEFACT Applied Technologies Group
Chair - UN/CEFACT XML Syntax Working Group
Co-Chair ISO TC154 Subcommittee for ISO 15000-5
LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The opportunity to make a difference has never been greater

-----Original Message-----
From: Stephen Green <stephen_green@seventhproject.co.uk>
To: ubl@lists.oasis-open.org <ubl@lists.oasis-open.org>
Sent: Wed Jul 20 10:25:03 2005
Subject: Re: [ubl] Discussion of substitution groups

Of course, the version attribute of the schema
is useless in this regard, as would be annotations
for CCTS which, too, are only held in the schema.
Neither can be referenced in the instance, only,
correct me if I'm wrong, the namespace and the
schemaLocation (which could be vague) can
appear in the instance to identify a schema or
an identifier within the schema in a well-known,
standard way. Creating a BIE so that something
else in instances does the same job, or worse, putting
that data into another document separate from the
instance, IMHO just moves the version data to somewhere
far less well-known, far less established.

Besides, I though it was intended that UBL supports
uses which are independant of ebXML, so forcing
use of CCTS-aware registries seems contrary to that
(if that is the alternative being offered to XSD derivation).

Likewise, adopting approaches as alternatives to
straightforward (though complex) uses of XSD seems
contrary to another NDR first principle of UBL.


        I doubt even more whether
        the version attribute could do the job. I doubt
        more still that it could be done with a UBL BIE
        for version.
        11. I hope nobody suggests that the version
        annotation in the schema be used !!  :-)

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