Re: [ubl-dev] Creating a new document... where to start?

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2004-06-22 20:55 +0100, Stephen Green wrote:
>You expound on 'constraints' and explain that XSD needn't be used
>to express them,
>
>but:-
>
>If XSD were to be used;
>
>Is there a (standard or accepted) way to say in or with the XSD
>what *kind of constraint* we are using? (I refer to the kinds of constraint
>at the end of your message)

Nope, not that I can think of.

>If not, can we invent one?

Not that would be schema expression independent (so as to allow schema 
expressions in many possible schema expression languages to determine it).

If we had an attribute or element in the instance, we might imply the 
semantic of "standardized full UBL" when that information item is absent, 
or "contextualized UBL" when the information item is present, and then 
publish a mechanism by which we syntactically represent context in the 
information item.

Say it were an attribute ... when absent in the instance, a processing 
application can assume it has the full range of UBL to expect.  When 
present in the instance, it might have values, say "SBP" for the small 
business profile, or "SBP:Auto" for the small business profile used in the 
automotive industry.

Then, we could add the constraint to each profile that the context 
information item be properly formatted for that profile ... then when you 
validate the instance against the profile, rogue values would be flagged, 
and when you validate the instance against full UBL all values would be 
acceptable.

But I'm wary of signalling the context physically in the instance ... but I 
don't know why I'm uneasy about that.  On the surface it seems to make 
sense: an application can recognize from the context which set of 
supplemental or derivative constraints are needed for validation.  But I 
think the reason goes very deep.

>P.S.  I guess 'context' gives us a way to say the *reason* for the
>constraint(s)

Yes, but its "messy".  Not only would we have to introduce such an 
information item into UBL 1.1, but I'm wondering if it is somehow breaking 
the arbitrariness of the flexibility of applying different schemas to 
different instances.  Perhaps not ... I am anxious to hear other users' 
comments.

You see, the thing is that an application that is tied to the SBP need only 
validate that an instance fits the SBP constraints on top of the UBL 
constraints ... of what use is a signal to say "this is an SBP instance" 
when a validation task will tell an application that anyway.

In fact, maybe now I'm thinking it is too limiting to actually tag a UBL 
instance to be an SBP instance ... what if a fully-supported UBL 
application outputs an XML instance that meets the user's needs, and it 
just coincidentally happens to meet the SBP constraints: an SBP application 
will successfully work with it because it passes the SBP constraints.  If 
it doesn't pass the constraints then it could never have been used.  If the 
SBP were looking for a signal, and that signal either wasn't there or we 
made the signal a mandatory part of the SBP profile, then the user loses 
out on possible benefits of using the SBP software that they would have 
been able to use had the validation been based solely on the presence of 
UBL information items, not on the value of a magic attribute.  But without 
the explicit signal the instance is simultaneously usable in all of the 
possible UBL contexts to which it validates.

So all that thinking aloud to come to the conclusion that, "no", don't put 
anything into the instance to signal it is an SBP instance .... just let 
validation assess that it is an SBP instance so as to put the burden back 
on the application and the flexibility back in the hands of the 
users.  Whenever they happen to create an instance that passes SBP 
validation, they have the flexibility to use SBP software.  If their 
particular needs one Thursday afternoon requires them to use additional 
properties, then they have those additional properties and SBP software 
rejects the instance, but that's okay because the user should have avoided 
those properties and validated the SBP constraints if it was important that 
they had to use SBP software.  And, from time to time users may have 
instances that are simultaneously usable in software that supports a number 
of different profiles, and then they don't have to do anything at all to 
take advantage of all of that software.

...................... Ken

--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal