UBL Naming and Design Rules SC

Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)

  • 1.  Re: [ubl-ndrsc] Fw: [ubl-lcsc] ccts Annotation Structure (fwd)

    Posted 07-01-2003 15:34
    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