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: RE: [ubl-dev] SBS and Restricted Data Types


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




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