RE: [ubl] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types

["Crawford, Mark" <mark.crawford@sap.com>]

Stephen,

> Following the conversations prompted by Joseph Chiusano I've an idea
> UBL might need, besides its Codelist Methodology, a general 
> methodology
> for at least restricting datatypes and maybe extending them in some
> cases.

See the content and supplementary component restrictions specified in
CCTS.  Since UBL claims conformance, it should follow the spec with
respect to creating qualified datatypes. The NDRs already give you the
methodology to instantiate this through qualified datatypes.

Kind Regards,

Mark 

 

> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
> Sent: Monday, May 08, 2006 2:10 PM
> To: ubl-dev@lists.oasis-open.org; ubl@lists.oasis-open.org
> Subject: [ubl] Datatype Methodology RE: [ubl-dev] SBS and 
> Restricted Data Types
> 

> 
> I was thinking that it is possible with UBL to extend and restrict
> enumerated codelists without it being called customisation. Yet to do
> this with other datatypes it might be necessary at the present to call
> it customisation. How about in future adding to the Codelist 
> Methodology
> a way to do the same or similar (as one can for codelists) with other
> datatypes.
> 
> A trading agreement which limits the currencies used to just USD might
> be such that a document with other currencies included isn't regarded
> as valid. The codelist methodology allows for this. We seem to need a
> way to apply such criteria to datatypes other than codes. In 
> some cases
> it might be that an instance is invalid with Text types having an over
> long string value. In other cases it might be that they 
> aren't invalid but
> an non-fatal exception is raised (the latter being more along 
> the lines
> of the SBS subsetting methodology).
> 
> Maybe the latter could be called 'UBL subsetting' and the former 'UBL
> profiling' (the codelist methodology seeming to suggest 'UBL 
> profiling'
> for codelists).
> 
> All the best
> 
> Stephen Green
> 
> 
> 
> Quoting stephen.green@systml.co.uk:
> 
> > Hi
> >
> > Continuing on outcomes of the ubl-dev UBL 2 SBS/datatypes 
> discussion:
> >
> > I'm not too keen on relaxing the SBS business rules to 
> accommodate datatype
> > restrictions.
> >
> > Maybe the restrictions should be relaxed rather than the 
> rule -  to remain
> > as inclusive to all businesses (no-one should be excluded 
> from use of the
> > SBS who would be able to use unsubsetted UBL).
> >
> > I'd think of making the restrictions a guideline of what is 
> appropriate
> > for a particular datatype. That way an instance would be accepted as
> > valid; but what would be grounds for rejection? I suggest 
> it shouldn't be
> > actually rejected if it is valid but might need to be 
> excepted and diverted
> > for human input if the strings, sayt are too long; but 
> sending systems would
> > know that this might happen and choose to avoid it out of proper 
> > consideration,
> > as with most uses of markup languages. Those who write web 
> pages which are
> > too long know, for instance, that some systems such as 
> computers with dialup
> > might not be able to reach the end of the document in a 
> reasonable time, but
> > the XHTML would still be 'valid' and browsers probably 
> wouldn't reject it
> > but a warning about the size would be appropriate in some systems.
> >
> > This would answer the need to keep in pace with changing 
> technology - the
> > guidelines could change as systems evolve but without 
> changing the validity
> > status of older documents. In particular, if something like 
> PDA use becomes
> > popular, older valid instances would still be strictly 
> speaking valid with
> > such devices but there could be a guide about what might 
> have to generate
> > a warning (there could be a set of guidelines for PDAs without 
> > forcing senders
> > to change what they send in this regard, but allow them to 
> change if they
> > wish to support such receiving systems well).
> >
> > Still needs plenty of thought I guess. Maybe this would be 
> best for UBL 2.1+
> >
> > Or it could be a supplement to the UBL 2 SBS produced 
> later, after UBL 2.
> >
> > All the best
> >
> > Steve
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> > at:
> > 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>