[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
Joe,
Any chance you could say how substitution groups might be
useful in your situation?
All the best
Steve
Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
> Oops, meant to answer the rest of the questions:
>
> <Quote>
> If redefine were used, how useful would xsi:type be? Not very I suspect,
> if again the schema doesn't enforce the restriction but if, despite an
> instance using the redefined schema as the schema location, the onus is
> on the instance producer to decide whether the restricted datatype is
> used: after all it is the receiving system which wants the restriction.
> </Quote>
>
> I believe xsi:type is required for redefine, not optional - so I believe
> it's beyond the question of it being useful (though opinions on this are
> valid of course). The onus indeed is on the instance producer to decide
> whether the restricted datatype is used - which of course adds
> additional complexity to producing the instance (and a margin for error
> by specifying the incorrect xsi:type value).
>
> <Quote>
> How about just redeclaring everything in a new schema, almost exactly
> the same as the original but with the restrictions - with or without the
> same namespaces?
> </Quote>
>
> Always an option - not necessarily good for interoperability, IMO, but
> in some cases it may be the best resort. For us (the initiative I am
> working on), I see other options such as substitution groups or CAM. For
> adding additional elements, there is also the combination of
> substitution groups and NVDL (if the additional elements are in a
> separate namespace), or CAM.
>
> 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:41 PM
> To: Chiusano Joseph
> Cc: ubl-dev@lists.oasis-open.org
> Subject: RE: RE: [ubl-dev] Datatype Methodology RE:
> [ubl-dev]SBSandRestricted Data Types
>
> Hi Joe
>
> Yep I admit it - I was trying to use xsi:type with substitution groups.
> Ooops. Still, the problem remains then that one can't actually use the
> substitution group to restrict the datatype since there is no 'abstract'
> declaration in the original schema and no way to prevent the
> unrestricted cbc:Name being valid in an instance. Is that correct?
>
> If redefine were used, how useful would xsi:type be? Not very I suspect,
> if again the schema doesn't enforce the restriction but if, despite an
> instance using the redefined schema as the schema location, the onus is
> on the instance producer to decide whether the restricted datatype is
> used: after all it is the receiving system which wants the restriction.
>
> How about just redeclaring everything in a new schema, almost exactly
> the same as the original but with the restrictions - with or without the
> same namespaces?
>
> Many thanks
>
> Steve
>
>
>
>
> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>
>> Steve,
>>
>> Both datatypes - "cst:MyNameType" and "cbc:Name" - would be valid in
>> an instance, only in that the elements declared to be of those
>> datatypes in the example below ("cst:CarrierName" and "cbc:Name") can
>> both appear in instances, and "cst:CarrierName" can be substituted for
> "cbc:Name"
>> wherever "cbc:Name" appears. Is that what you meant by both datatypes
>> would be valid in an instance?
>>
>> Unless my recent posting was incorrect, xsi:type is not used with
>> substitution groups - which is why you may have been having the
>> problems with tools that you mentioned below, unless you meant that
>> you have had problems using xsi:type with redefined datatypes and
> abstract datatypes.
>>
>> 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:30 AM
>> To: Chiusano Joseph
>> Cc: ubl-dev@lists.oasis-open.org
>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev]
>> SBSandRestricted Data Types
>>
>> Hi Joe
>>
>> But doesn't substitution groups mean that * both * datatypes would be
>> valid in an instance? I so far haven't been able to get the xsi:type
>> method to work well with the tools I use.
>>
>> All the best
>>
>> Steve
>>
>>
>>
>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>
>>> Thanks Steve. Regarding the following:
>>>
>>> <Quote>
>>> The derivation looks workable: base an element on the qualified
>>> rather
>>
>>> than unqualified datatype using redefine or a substitution group.
>>> </Quote>
>>>
>>> I don't believe redefine will work here, but substitution groups
> will.
>>> Here's my train of though (please tell me of any derailment:)t:
>>>
>>> - As you mentioned, we would create a qualified data type - it would
>>> look as follows (based on cbc:NameType):
>>>
>>> <xsd:simpleType name="MyNameType">
>>> <xsd:restriction base="cbc:NameType">
>>> <xsd:maxLength value="35"/>
>>> </xsd:restriction>
>>> </xsd:simpleType>
>>>
>>> - At this point, we need to create a new element that is of
>>> "MyNameType". I don't believe we can use redefine here, as (as you
>>> know) redefine means to redefine a data type. What data type would we
>
>>> redefine? If we redefined the "udt:NameType" or "cbc:NameType" data
>>> types, we would have the same issue that I referred to earlier (a
>>> ripple effect).
>>>
>>> - However, we could use substitution groups, as you pointed out (but
>>> knowing the dangers of using this approach, as highlighted in the
>>> long
>>
>>> threads between XML-DEV and UBL-DEV X months ago asking for input on
>>> usage of substitution groups). Here is an example in which a new
>>> element named "CarrierName", which is of data type "cst:MyNameType"
>>> ("cst:" for "custom" namespace) can substitute for the head element
>> "cbc:Name"):
>>>
>>> <element name="CarrierName" type="cst:MyNameType"
>>> substitutionGroup="cbc:Name"/>
>>>
>>> So "cst:CarrierName" can appear in XML documents in place of
> cbc:Name.
>>
>>> I am also wondering if one can use the same name for the substituting
>
>>> and head elements but different namespaces (i.e. instead of
>>> "CarrierName", use "Name" which would be in the "custom" namespace -
>>> I
>>
>>> have never tried this (will test it out).
>>>
>>> Thanks,
>>> Joe
>>>
>>> Kind Regards,
>>> 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: Thursday, May 11, 2006 2:51 AM
>>> To: ubl-dev@lists.oasis-open.org
>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
>>> andRestricted Data Types
>>>
>>> Joe
>>>
>>> Hi. Regarding the technicality of whether W3C XML Schema derivation
>>> can be used to restrict the datatypes in UBL, it seems more
>>> plausible,
>>
>>> looking at the examples below, that it might be allowed. The correct
>>> way to do it, I think, is to create a qualified datatype in one's own
>
>>> qualified datatype schema module. I have an action item to try this
>>> sort of thing as part of the quality control of the next set of draft
>
>>> schemas, either during or after the coming plenary meeting in
>> Brussels.
>>> The derivation looks workable: base an element on the qualified
>>> rather
>>
>>> than unqualified datatype using redefine or a substitution group.
>>> It looks workable depending perhaps on how the qualified datatype is
>>> based on the unqualified datatype it restricts; whether it uses
>>>
>>>
>>> <xsd:simpleType name="MyIndicatorType">
>>> <xsd:restriction base="xsd:boolean">
>>> <xsd:pattern value="true"/>
>>> </xsd:restriction>
>>> </xsd:simpleType>
>>>
>>> or
>>>
>>> <xsd:simpleType name="MyIndicatorType">
>>> <xsd:restriction base="udt:IndicatorType">
>>> <xsd:pattern value="true"/>
>>> </xsd:restriction>
>>> </xsd:simpleType>
>>>
>>> All the best
>>>
>>> Stephen Green
>>>
>>> Quoting stephen.green@systml.co.uk:
>>>
>>>> Hi Joe,
>>>>
>>>> For example in UBL 1.0 we have the unqualified datatype 'AmountType'
>>>>
>>>> <xsd:complexType name="AmountType">
>>>> <xsd:simpleContent>
>>>> <xsd:restriction base="cct:AmountType">
>>>> <xsd:attribute name="amountCurrencyID"
>>> type="xsd:normalizedString"
>>>> use="required"/>
>>>> <xsd:attribute
>>> name="amountCurrencyCodeListVersionID"
>>>> type="xsd:normalizedString" use="optional"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleContent>
>>>> </xsd:complexType>
>>>>
>>>>
>>>> and a corresponding restriction of that UBLAmount which, since it is
>
>>>> based on the unqualified datatype and a restriction of the same,
>>>> would
>>>
>>>> now be called a 'qualified datatype' but was, in UBL 1.0, then
>>>> called
>>
>>>> a 'specialized datatype'
>>>>
>>>> <xsd:complexType name="UBLAmountType">
>>>> <xsd:simpleContent>
>>>> <xsd:restriction base="udt:AmountType">
>>>> <xsd:attribute name="amountCurrencyID"
>>> type="cur:CurrencyCodeContentType"
>>>> use="required"/>
>>>> <xsd:attribute
>>> name="amountCurrencyCodeListVersionID"
>>>> type="xsd:normalizedString" use="optional" fixed="0.3"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleContent>
>>>> </xsd:complexType>
>>>>
>>>> In this case the main restriction is that the amountCurrencyID is
>>>> limited to the one codelist (which is the ISO currency codelist) but
>
>>>> the value of the amountCurrencyCodeListVersionID attribute is also
>>> restricted to '0.3'.
>>>>
>>>> [At the risk of confusing folk, I'd note that in UBL 2 the Amount is
>
>>>> itself restricted to having the ISO currency codelist as implemented
>
>>>> by CEFACT's ATG2 so there is no need for the qualified datatype.]
>>>>
>>>> A simpler example, though fictional, would be that if there was a
>>>> need
>>>
>>>> for a boolean that could only be true, one would have to restrict
>>>> the
>>
>>>> unqualified Indicator datatype which has a restriction to 'true' and
>>> 'false'
>>>> and base the new datatype on that Indicator, giving it new name
>>>> perhaps (though it would get a new namespace anyway) and restricting
>
>>>> it to 'true' only.
>>>> In UBL 2 prd there is the ATG2 schema
>>> 'UnqualifiedDataTypeSchemaModule-2.xsd'
>>>> with an Indicator type
>>>>
>>>> <xsd:simpleType name="IndicatorType">
>>>> <!-- documentation removed -->
>>>> <xsd:restriction base="xsd:boolean">
>>>> <xsd:pattern value="false"/>
>>>> <xsd:pattern value="true"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleType>
>>>>
>>>> A corresponding, restricted, qualified datatype might therefore be
>>>>
>>>> <xsd:simpleType name="MyIndicatorType">
>>>> <xsd:restriction base="xsd:boolean">
>>>> <xsd:pattern value="true"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleType>
>>>>
>>>> or
>>>>
>>>> <xsd:simpleType name="MyIndicatorType">
>>>> <xsd:restriction base="udt:IndicatorType">
>>>> <xsd:pattern value="true"/>
>>>> </xsd:restriction>
>>>> </xsd:simpleType>
>>>>
>>>> (I'm not yet certain which of the above is most correct - perhaps it
>
>>>> is a matter of interpretation of the CCTS.)
>>>>
>>>>
>>>> All the best
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>>>>
>>>>> Thanks Steve. Please remind me again what a "qualified" datatype
>>>>> would be? Would it be, for example, a data type whose name (and
>>>>> definition) reflects the restriction that we are speaking of? So
>>>>> for
>>
>>>>> example, instead of the unqualified "IdentifierType", we would have
>
>>>>> an identifier type that has a pattern restriction and it would be
>>>>> called "SSNIdentifierType"?
>>>>>
>>>>> 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: Wednesday, May 10, 2006 5:38 PM
>>>>> To: ubl-dev@lists.oasis-open.org
>>>>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS
>>>>> and
>>>
>>>>> Restricted Data Types
>>>>>
>>>>> Hi Joe
>>>>>
>>>>> Absolutely. Sorry, I'd forgotten this and it isn't all that
> obvious.
>>>>> The thing is that the datatypes UBL uses are mostly what the CCTS
>>>>> calls unqualified. To redefine them one really (as, thankfully,
>>>>> Mark
>>
>>>>> Crawford explained earlier) has to create new datatypes based on
>>>>> them
>>>
>>>>> which are called qualified datatypes. The element based at present
>>>>> on
>>>
>>>>> the unqualified datatype would have to somehow be replaced, I
>>>>> think,
>>
>>>>> not being able to see how to do it any other way, with a new
>>>>> element
>>
>>>>> based on the restricted qualified datatype. To my mind it needs a
>>>>> new
>>>
>>>>> element and a restricting out of the old element, rather than a
>>>>> redefine of the old element. I can't see how to do the latter with
>>> XSD derivation.
>>>>> If an element was based on a UBL-qualified datatype then maybe,
>>>>> since
>>>
>>>>> it would be under UBL control as it were, one could use XSD
>>>>> redefine
>>
>>>>> to restrict it. That is interesting. It may mean that restriction
>>>>> is
>>
>>>>> limited by use of an unqualified datatype, especially when CCTS
>>>>> (and
>>>>> UBL) compliance is required.
>>>>> I think the same applies to the XSD substitution group method.
>>>>>
>>>>> All the best
>>>>>
>>>>> Stephen Green
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> [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]