OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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.

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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]