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] SBSandRestricted Data Types


Hi Steve,

Thanks for the proposed approach below. I believe we have the same issue
here that described in my recent postings, where although substitution
groups will work in general, there is no mechanism within W3C Schema to
control when substitutions are made (i.e. to control which occurrences
of the head element are substituted). So in the approach below, there
would be no way to ensure/enforce that the new PartyName element (call
it "MyPartyName") is not "incorrectly" substituted for PartyName. 

Also, I don't believe that there is any advantage to "widening the
scope" of the substitution by having it apply to the the PartyName
element vs. the cbc:Name element, unless there were multiple subelements
of PartyName that needed to be used as substitutions. Since there is
only one (at least for our examples), one could scope the substitution
group to just the cbc:Name element and its corresponding (substitutable)
"MyName" element.

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@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Friday, May 12, 2006 3:42 AM
To: Chiusano Joseph
Cc: Stephen Green; ubl-dev@lists.oasis-open.org
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%3Aredef
> in
> 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]