[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)
I am on vacation throughout July. Could someone else take up my part in this dialogue? I don't want to let it hanging in the air, these are important questions (though I wish we didn't have to continue revisiting...) but I don't think answering them really corresponds to what one should be doing while on vacation... Thanks! Chin Chee-Kai wrote: > I'm sure there were due considerations given to the idea of > two schemas (A & A' using your terminology) per UBL-schema. > I'm just trying to put the rule into perspective now that > we have some form of draft schemas to talk about. > > Say, A' is the one with documentation. People would and > could strip documentation away from A' to get A, where > > A = A' (modulo documentation elements that > do not affect processing in any way) > > So the part about "*and* change the namespace" does not have > to necessarily take place, unless there is a simultaneous > contextualization into the user's operating environment. > > There's no tons-and-tons of documentation now for the draft. > But that possibility could exist in user environment, especially > for contextualization purposes, they wish to document differences > made, etc. So when that ton-and-tons of documentation do > surface, perhaps user could "point" from their schemas using > URLs to a full-fledged page to document that point in their > schema. > > Complete documentation cannot be indefinitely stuffed > into schema as if schema is the best way to store documentation. > So the "tons-and-tons of documentation" scenario ought not > to happen (even though it can), and may be even stated as > an NDR checklist item as a form of best practice. > > Stripping documentation as part of optimization does not warrant > a change of namespace since the stripping may be carried out in > various programming styles, such on-the-fly, cached, pre-compiled > binaries, etc. The way UBL annotates the element using > xsd:annotation, it also falls outside of schema checkers, > so that there is no need to modify schemas and change namespaces. > > As a result, there is no need to specify the maintenance of > two identical schemas (A & A') where they differ only in > annotations. > > > Best Regards, > Chin Chee-Kai > SoftML > Tel: +65-6820-2979 > Fax: +65-6743-7875 > Email: cheekai@SoftML.Net > http://SoftML.Net/ > > > On Mon, 30 Jun 2003, Eduardo Gutentag wrote: > > >>>Although I agree with you in principle, the problem is that if >>>we were to produce enormous schemas with tons and tons of >>>documentation embedded, carrying some ubl namespace, people who >>>wanted to use them with any kind of hope of acceptable >>>performance would have to strip the documentation away *and* >>>change the namespace. >>> >>>It was because of this concern (that is, allowing people to say >>>they use UBL schemas) that we came up with the idea of two >>>sets of schemas carrying the same namespaces names (that is, >>>schemas A and A' being both in namespace UBL:A if the only >>>difference is documentation.) Perhaps we should play with the >>>idea of having A in namespace UBL:A and A' in namespace UBL:A' ? >>> >>>(where UBL:A is just a shorthand reference to the UBL namespaces, >>>not to be taken as implying that it is an UBL namespace name...) >>> >>>Chin Chee-Kai wrote: >>> >>>>Again, this two schemas per model rule is also something >>>>I feel is rather stringent to be stated as a rule, or that >>>>it is redundant. >>>> >>>>Developers and users will find their own most suitable form >>>>of optimizing for processing. It shouldn't be a specified >>>>form of rule for such purposes. >>>> >>>> >>>> >>>> >>>>Best Regards, >>>>Chin Chee-Kai >>>>SoftML >>>>Tel: +65-6820-2979 >>>>Fax: +65-6743-7875 >>>>Email: cheekai@SoftML.Net >>>>http://SoftML.Net/ > > -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards | Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. | W3C AC Rep / OASIS TAB Chair
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]