[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBSandRestricted Data Types
Hi Joe I do get the feeling I'm clutching at straws here and as my later emails show, having done a few tests, I tend to agree that one might not be able to get susbtitution groups to work on just one element 'Name'. However, just a thought: what if the substitution is performed on an element PartyName which includes Name to make it use MyName, where MyName doesn't have susbtitution but just uses a new CCTS-compliant (thankyou Mark) qualified dataype qdt:Name35 which has the restricted string. I'm thinking it might then be that only the PartyName gets the new Name with its qdt:Name35 restricted datatype. I'll try this out. All the best Steve Quoting Chiusano Joseph <chiusano_joseph@bah.com>: > Additional clarification: > > <Quote> > You use redefine or substitution groups (which one especially depends on > whether you keep the same namespaces or use new ones) to redefine or > substitute the element or type based on the datatype (cbc:Name). ** The > key thing is you should be able to do this just with one occurance of > cbc:Name without affecting other Name elements. ** > </Quote> > > I'm so sorry to repeat this here from my last posting - but just wanted > to do so in case a clarification from the perspective of the above > explanation may uncover a different angle. Since element cbc:Name is of > data type cbc:NameType, a redefine of cbc:NameType would (unless I am > missing something) affect all elements that are defined to be of that > type - which in this case means, I believe, only cbc:Name. This then > means that all references to cbc:Name (of which there are many, as we > know) would reflect the redefined cbc:NameType. So if cbc:NameType were > redefined to have a max of 35 characters, that would mean that all > cbc:Name values (all references to that global element) can have a max > of 35 characters. So I believe that there is no way to enable this > change (max 35 characters) to affect only one occurrence of cbc:Name > without affecting other Name elements, when using redefine. > > <Quote> > How do you do it? I'd look back at those prototypes done by UBL and > posted in the archives. Some only seem to work when you use the UBL 2 > all-global schema design but at least one method (I believe it was > posted by Mike Grimley) allows it to work, I think, with xsd:redefine in > UBL 1.0. > </Quote> > > I will definitely peruse through my Google search results, in spite of > my observations above, in case I might be missing something: > > http://www.google.com/search?hl=en&lr=&q=Grimley+ubl+oasis+xsd%3Aredefin > e > > Thanks, > Joe > > Joseph Chiusano > Associate > Booz Allen Hamilton > > 700 13th St. NW, Suite 1100 > Washington, DC 20005 > O: 202-508-6514 > C: 202-251-0731 > Visit us online@ http://www.boozallen.com > > -----Original Message----- > From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] > Sent: Thursday, May 11, 2006 6:25 AM > To: ubl-dev@lists.oasis-open.org; stephen.green@systml.co.uk > Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS > andRestricted Data Types > >>> 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). The parser > validating against this would have to recognise the restricted datatype > (qdt:MyNameType) as being allowed for use as a redefinition or a > substitution (both according to W3C XML Schema derivation rules which > are quite complex) of the udt:NameType. It might depend on tools as to > which works best or it might depend on derivation rules as to which > works at all (or both may be correct and CCTS might say which should be > used - still debated a bit I think). > </TechnicalNote> > > Then the magic starts! > > You use redefine or substitution groups (which one especially depends on > whether you keep the same namespaces or use new ones) to redefine or > substitute the element or type based on the datatype (cbc:Name). ** The > key thing is you should be able to do this just with one occurance of > cbc:Name without affecting other Name elements. ** How do you do it? > I'd look back at those prototypes done by UBL and posted in the > archives. Some only seem to work when you use the UBL 2 all-global > schema design but at least one method (I believe it was posted by Mike > Grimley) allows it to work, I think, with xsd:redefine in UBL 1.0. > > >>>> >>>> However, this would cause a ripple effect across all other > references >>>> to the cbc:Name element within the Despatch Advice schema (through >>>> references within the Common Aggregate Components schema), which > would >>> >>>> in effect cause all other cbc:Name elements to be a max of 35 >>>> characters. This may or may not be the desired outcome - even if by >>>> chance all should be 35 characters, this of course will not always > be >>>> the case. > > Depends how you do it: see above. It may also depend for some methods on > use of UBL 2 with its all-global schema design, especially for > substitution groups. > > > > > >>>> >>>> So unless I am missing something (which someone will tell me I am >>>> sure:), the xsd:redefine feature will not work in this case. All the >>>> more reason we need alternate approaches. >>>> > > 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. > > Another alternative is Schematron second pass validation and prose or > XML > definition of the restrictions along the same lines as business rules > and codelists. > > Another is just don't do it and use the out-of-the-box schemas and maybe > a subset > like the SBS which allows acceptance as valid of all documents valid > against the schemas. > > That's a bit about the 'how' but it doesn't really answer the 'which' or > the 'whether'. > > All the best > > Steve > > > > >>>> Joe >>>> >>>> Joseph Chiusano >>>> Associate >>>> Booz Allen Hamilton >>>> >>>> 700 13th St. NW, Suite 1100 >>>> Washington, DC 20005 >>>> O: 202-508-6514 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> >>>> -----Original Message----- >>>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] >>>> Sent: Wednesday, May 10, 2006 3:41 PM >>>> To: David RR Webber (XML); Stephen Green >>>> Cc: ubl-dev@lists.oasis-open.org >>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS > and >>>> Restricted Data Types >>>> >>>> David, >>>> >>>> Thinking more about CAM here: How efficient and straightforward > would >>>> it be to restrict the data type of - picking a schema and element >>>> completely at random here - the Carrier Name element in the UBL 2.0 >>>> Despatch Advice schema to, say, a maximum of 35 characters? >>>> >>>> Here is the path to that element: >>>> DespatchAdvice/Shipment/Consignment/CarrierParty/PartyName/Name >>>> >>>> Thanks, >>>> Joe >>>> >>>> Joseph Chiusano >>>> Associate >>>> Booz Allen Hamilton >>>> >>>> 700 13th St. NW, Suite 1100 >>>> Washington, DC 20005 >>>> O: 202-508-6514 >>>> C: 202-251-0731 >>>> Visit us online@ http://www.boozallen.com >>>> >>>> -----Original Message----- >>>> From: David RR Webber (XML) [mailto:david@drrw.info] >>>> Sent: Wednesday, May 10, 2006 11:03 AM >>>> To: Stephen Green >>>> Cc: ubl-dev@lists.oasis-open.org >>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS > and >>>> Restricted Data Types >>>> >>>> Stephen, >>>> >>>> I follow your thoughts here. >>>> >>>> We're actively re-visiting on which pieces of the CAM template > should >>>> be required and which non-normative / extensible. >>>> >>>> Right now the <DataValidation> and <ExternalMapping> are optional. >>>> Also in jCAM Martin has implemented Maven with these so they are > fully >>> >>>> extensible - but obviously that is then non-normative - but I have > not >>> >>>> yet updated the spec' to reflect that change. It's a critical >>>> direction >>>> - the realization that you cannot perscribe everything for everyone > - >>>> and that instead - you provide normative tools for those parts > people >>>> expect the standard to - while giving flexiblity - but in a known > and >>>> predictable and re-usable way - for those peices they traditionally >>>> expect to have control over. >>>> >>>> The other normative sections are of course tailorable to match the >>>> particular implementors vision and can include only those feartures >>>> and parts that suit (it's just XML markup!). >>>> >>>> What I would expect is that the CAM template would be a base-line > one >>>> - that implementors could then refine and extend to their own local >>> needs. >>>> This I think is inline with the notion of SBS - having a jump-start >>>> kit that people can quickly use by default - and then refine and >>>> extend in practice. Use of <include> is critical to provide >>>> separation between such base-line templates and local extensions. > And >>>> then context is vital for people to understand the use model for > each >>> template. >>>> >>>> DW >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: Re: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS > and >>>> Restricted Data Types >>>> From: "Stephen Green" <stephen_green@bristol-city.gov.uk> >>>> Date: Wed, May 10, 2006 10:35 am >>>> To: <ubl-dev@lists.oasis-open.org> >>>> >>>> This makes me think UBL might be benefitted from CAM templates based >>>> on a profile of CAM which covers the gaps. Maybe one profile without >>>> the 'context' bit (CCTS concept of it, not CL methodology concept of >>>> document context) and one with (so one doesn't have to implement a >>>> full-scale CCTS context-sensitive system unless there is a need to). >>>> There may be other bits of CAM not needed in such UBL > implementations >>>> too, or parts which UBL duplicates which could be profiled-out. >>>> >>>> Stephen Green >>>> >>>>>>> "David RR Webber (XML)" <david@drrw.info> 05/10/06 15:02 PM >>> >>>> Chin, >>>> >>>> I was trying to not get into nitty-gritty angle bracket stuff - but >>>> here's a 20,000 foot view. >>>> >>>> The CAM template consists of 5 sections: >>>> >>>> <Header> >>>> <AssemblyStructure> >>>> <BusinessUseContext> >>>> <DataValidations> >>>> <ExternalMapping> >>>> >>>> We can equate the two <AssemblyStructure> and <BusinessUseContext> > to >>>> the layering approach - where UBL provides the structure definition > - >>>> and the context section then exposes the delta between the generic > and >>> >>>> subset. You can use <include> in the structure section to reference > a >>> >>>> particular UBL sample. >>>> >>>> Basically if you look in the <BusinessUseContext> section and you > see >>>> nothing - then you know people are using that included UBL sample >>> as-is! >>>> >>>> >>>> Otherwise - the Header can come into play next - because that is > where >>> >>>> you define your global context variables that you might need - for >>>> example boolean $export_order. >>>> >>>> So - in the context section you can have default rules - I would >>>> expect you to have these normally - as these apply to all context >>>> instances and use - these are identified in the XML by - >>>> >>>> <Rules><default><context> <!-- default rules --> > </context>/default> >>>> .... >>>> >>>> After that - you have specific context rules - here is where you > would >>> >>>> put the typical refinements and crosschecks (e.g. if $export_order >>>> then <export_manifest> required mandatory element, etc) associated >>>> with your use case - these can reference global $ variables - or be >>>> value driven within the data stream - e.g. : >>>> >>>> <context >>>> condition="PHS398_ResearchPlan:TypeOfApplication='Resubmission'"> >>>> <constraint action="makeMandatory(//RR_SF424:FederalID)" /> >>>> <constraint action="setLength(//RR_SF424:FederalID,15)" /> >>>> </context> </Rules> >>>> >>>> So you can see the deltas are explicitly called out and labelled by >>>> context - and you can find them quickly without having to grope >>>> through the XML structure itself line-by-line. >>>> >>>> CAM also provides you with a library of 30+ functions - so you can >>>> manipulate the structure tree - pruning or selecting, changing from >>>> optional to mandatory, etc, rule driven. I like to say that XSD >>>> schema provides you with a picture map of all the possible > structural >>>> varients that you may encounter - whereas CAM restricts this to the >>>> exact structure layout that you need for your particular context and >>> usage. su >>>> >>>> DW >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and >>>> Restricted Data Types >>>> From: Chin Chee-Kai <cheekai@softml.net> >>>> Date: Tue, May 09, 2006 9:21 pm >>>> To: UBL-Dev <ubl-dev@lists.oasis-open.org> >>>> >>>> Hi David, >>>> >>>> Very much so, certain level of semantics processing that is common > may >>> >>>> be extracted and stored away as what you call sub-component > templates. >>>> >>>> You mentioned that CAM already handles the deltas by making them >>>> explicit so business users can readily inspect them. It sounds > good, >>>> but in what manner does CAM store and manifest the deltas? Let's > say >>>> we use the string length restriction from infinite to 30-char >>>> for example. How does CAM indicate this delta? (Sorry for asking >>>> something so simple relative to CAM as I haven't much exposure to >>>> CAM yet). If he way CAM does it is usable, there may be something >>>> which UBL customisation could incorporate. >>>> >>>> >>>> Best Regards, >>>> Chin Chee-Kai >>>> SoftML >>>> Tel: +65-6820-2979 >>>> Fax: +65-6820-2979 >>>> Email: cheekai@SoftML.Net >>>> http://SoftML.Net/ >>>> >>>> >>>> On Tue, 9 May 2006, David RR Webber (XML) wrote: >>>> >>>>>> Chin, >>>>>> >>>>>> ... >>>>>> >>>>>> Another tool here is <include> statements. Where a template >>>>>> fragment is created that handles default processing of common > blocks >>> >>>>>> of XML content (address is an obvious one). Being able to create >>>>>> sub-components templates - breaking the overall processing down > into >>> >>>>>> smaller more manageable chunks is another notion that helps to >>>>>> implement concepts such as SBS. >>>>>> >>>>>> DW >>>>>> >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> 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/ >>>> >>>> >>>> >>>> > --------------------------------------------------------------------- >>>> This publicly archived list supports open discussion on implementing >>>> the UBL OASIS Standard. To minimize spam in the archives, you must >>>> subscribe before posting.su >>>> >>>> [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/ >>>> >>>> > --------------------------------------------------------------------- >>>> 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/ >>>> >>>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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/ >> >> > > > > > --------------------------------------------------------------------- > 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]