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


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]