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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: [ubl-dev] Just for the record, I now count three gaps with XSD


Chee-Kai,

If UBL were building schema without reference to the syntax neutral CC
library, <redefine> might have some value to UBL developers in moving
from version to version.  However, with the UBL methodology of first
creating the CC models, then using NDR to systematically develop the
schema, I see no value in <redefine> for UBL.

<redefine> might be of some value to customizers who wish to take the
UBL constructs and modify them to their own purposes, but its use by UBL
would appear to unnecessarily break the relationship with the CC model.

Kind Regards,

Mark 

 

> -----Original Message-----
> From: Chin Chee-Kai [mailto:cheekai@softml.net] 
> Sent: Sunday, June 04, 2006 10:13 PM
> To: UBL-Dev
> Subject: Re: [ubl-dev] Just for the record, I now count three 
> gaps with XSD
> 
> Stephen,
> 
> Hi, just some comments in case they could be of use.
> 
> Several readings of the XSD document appear to bring across the
> point to me that <redefine> is more suited for owner's upgrade
> or modification of owner's data types/elements, rather than as
> a general mechanism for independent schema authors to share and
> reuse types/elements.  This means, if that interpretation of
> <redefine>'s usage is proper, <redefine> would be more for UBL TC's 
> own redefinition of its types/elements, such as during v1.0 to
> v2.0 transition, or other purposes.   XSD doesn't forbit other
> uses of <redefine>, of course, but I suppose if the mechanism
> is not designed for another purpose but still adapted to fit,
> somewhere minor problems might kick in, if not major ones.
> That's just a potential concern, not to say it's so obviously
> dangerous that <redefine> shouldn't be used.
> 
> 
> On <substitutionGroup>, perhaps it's already an obvious point.
> But just a caution that for a given schema, if there are  N1 
> substitutable elements (A11, A12, ... A1_N1) 
> for element E1 (assuming non-abstract), N2 elements
> (A21, A22, .... A2_N2) for E2 , etc,  the resulting data
> instance set that is described by that schema would be much 
> larger than
> what might be intended.  
> 
> If what is intended is to accept instances when A11 is accepted,
> then also insist on accepting A21 which appears elsewhere in the
> same data instance, or if A12 is accepted then insist on accepting 
> A22, and so on, then <substitutionGroup> really gives a rather
> bloated data set.  If data goes pass validation, they might not
> get picked up by application (as it expects A21 when it sees A11,
> for example).
> 
> Perhaps one could say this is a weakness of <substitutionGroup>,
> or one could say the whole idea of <subsitutionGroup> for 
> customisation shouldn't be started in  the first place as it
> isn't meant for such purpose.  Either way, used or not used,
> it's probably better that we don't allow more data than necessary 
> to go pass the first line of validation.
> 
> 
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6820-2979
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
> 
> 
> On Fri, 2 Jun 2006 stephen.green@systml.co.uk wrote:
> 
> >>I was unable to get to emails in the latter stages of the
> >>recent discussions, sorry.
> >>
> >>Just for the record, not wanting to spark further debate
> >>but open to contrary or confirming comment, I now count
> >>that there have been three key areas where UBL work has
> >>found a gap between e-commerce requirements and XSD (W3C
> >>XML Schema) features:
> >>
> >>first was ** Subsets ** (hence no schemas provided for the SBS)
> >>
> >>second was ** Codelists ** (enumerated datatype restriction 
> and extension)
> >>
> >>now the third seems to be ** Extension Points **
> >>
> >>We also, historically, had problems with use of substitution
> >>groups for customisation when there were already imports in
> >>the schemas (instances needed different prefix requirements
> >>after customisation from those they had before it).
> >>
> >>I also find problems using 'redefine' across 'imports' which
> >>would hinder its use for minor versioning of modular schemas
> >>which already use 'import'. There have been problems trying
> >>to redefine schemas where the redefinitions are needed both
> >>sides of imports (or several imports in UBL's case).
> >>
> >>On the plus side though, I did manage to get substitution groups
> >>working to some extent with UBL's CCTS-datatypes in a way which
> >>was CCTS compliant, I think (subsituting elements based on types
> >>based on CCTS 'qualified datatypes' based on CCTS 'unqualified
> >>datatypes'). This was to customise UBL 1.0. Of course there are
> >>known limitations in customising UBL 1.0 this way already being
> >>possibly fixed with the design for UBL 2 (UBL NDR 2).
> >>
> >>I'll be presenting my own slant on this later in June at an XML UK
> >>meeting in Reading (Town Hall), UK on coming 27th June at 10.35
> >>BST if anyone is near enough to come and heckle :-)
> >>
> >>All the best
> >>
> >>Stephen Green
> >>
> >>
> >>
> >>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>This publicly archived list supports open discussion on 
> implementing the UBL OASIS Standard. To minimize spam in the
> >>archives, you must subscribe before posting.
> >>
> >>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> >>Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> >>List archives: http://lists.oasis-open.org/archives/ubl-dev/
> >>Committee homepage: http://www.oasis-open.org/committees/ubl/
> >>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >>Join OASIS: http://www.oasis-open.org/join/
> >>
> >>
> 
> 
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on 
> implementing the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
> 
> 


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