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


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]