[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBSandRestricted Data Types
Hi Joe
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]