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: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS andRestricted Data Types


Hi Ken

I think (not sure without trying) you can create my:Name and substitute cbc:Name
with it just in particular document contexts. I think redefine works similarly where
you redefine the context to use my:Name instead of cbc:Name just in that 
document context. I wouldn't say it is exactly trivial and might not be something
traders have access ready to (even with a decent IT department). Hence doing
this once on behalf of many SMEs would seem appropriate but even then I wouldn't
want to do it if there were no reason to.

All the best

Steve


>>> "G. Ken Holman" <gkholman@CraneSoftwrights.com> 11/05/06 11:53:10 >>>
At 2006-05-11 11:24 +0100, Stephen Green wrote:
> >> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> >>
> >>> P.S. Regarding xsd:redefine: A redefine of this element (Carrier Name,
> >>
> >>> represented as cbc:Name) does not seem possible (unless my dusting off
> >>
> >>> of the xsd:redefine feature brings misunderstanding with it), as one
> >>> would need to redefine its type, which is cbc:NameType, to have a max
> >>> of
> >>> 35 characters rather than an unlimited number.
>
>To summarise: the solution has been designed, so it seems to me at 
>least, on the
>premise that you create a new datatype based on the existing 
>datatype (or maybe
>based on the same xsd:datatype as the existing datatype, if that 
>will work) and
>restrict that.
>
>So the cbc:Name might use the datatype udt:NameType which is based 
>on xsd:string.
>You define a qualified datatype qdt:MyNameType with either
>
>                 <xsd:restriction base="xsd:string">
>or
>                 <xsd:restriction base="udt:NameType">
>
>Then restrict it
>
>                 <xsd:restriction base="xsd:string">
>                         <xsd:minLength="1"/>
>                         <xsd:maxLength="35"/>
>                 </xsd:restriction>
>or
>
>                 <xsd:restriction base="udt:IndicatorType">
>                         <xsd:minLength="1"/>
>                         <xsd:maxLength="35"/>
>                 </xsd:restriction>
>
><Technical Note>
>I need to test which of these works at all (or best).

Won't you get a "duplicate definition" on cbc:Name because the UBL 
NDR forces all elements to be globally defined?

Recognizing, of course, that *every* occurrence of cbc:Name will be 
affected by this, but that might be just fine in this scenario.

But (while I don't have the time to test it myself), my gut feel is 
that the validator will complain that your new global definition of 
cbc:Name conflicts with the existing global definition of cbc:Name in 
the (read-only) UBL schemas, and it won't work.

At least that is my recollection of my attempts with the UBL schemas 
at redefinition.

>An alternative is to completely rewrite the schemas, relying on some clever
>developers to ensure that there is full derivation-rule backwards 
>compatibility
>with regard to instances and validation. I think that is the present 
>ATG2 approach.

Or (if I can find the time) by an exhaustion approach which, I 
believe, will be definitive and programmatically provable.

>Another alternative is Schematron second pass validation and prose or XML
>definition of the restrictions along the same lines as business 
>rules and codelists.

Yes, though I'm not fond of using Schematron for structural 
constraints ... structural co-occurrence constraints yes, but not 
just for simple structural constraints.

>That's a bit about the 'how' but it doesn't really answer the 
>'which' or the  'whether'.

Time and trial will tell.

I'm anxious to see your results, Stephen.

. . . . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com 
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/ 
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc 
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal 


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