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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

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

Subject: Re: [ubl-cmsc] Examples Review


thanks for explaining what you meant by adapter schema. I believe I'm
starting to understand better where you're going, though perhaps we should
talk more about this tomorrow.

As to the use, or rather the decision not to use xsd:redefine, I have to
confess once again (as I did at our last f2f) that I don't remember what
where the reasons for our decision not to use it.

Does anybody in this SC remember the arguments against xsd:redefine in
this context?

Dan Vint wrote:
> I'm starting to think about reviewing the examples now.
> I think as standalone snipets they are in general fine, but I think we 
> need more context. There is a reference to using I think the UR-type and 
> then extending that in such a way that it requires the use of xsi:type 
> in the document stream. This seems to be pointing at a particular to 
> structure and manage the extensions - I would like to nail this down a 
> little better.
> First I would like to discuss the goals of this methodology and see if 
> they agree with my expectations:
> 1) My extensions and required setup are portable and reusable from one 
> UBL version to the next.
> 2) I'm not directly editing or modifying the UBL schema(s) so I can 
> achieve #1.
> 3) I'm importing the UBL schema to achieve #2 and the result is 
> identified with a new hybrid namespace
> 4) The methods used to extend and manage the extensions by hand are 
> compatible with those of the future black-box method/tool. (Saw this in 
> the spec already)
> Items 1 and 2 are the important ones in my book because I want this to 
> be maintainable and easily ported from one version to the next or 
> possibly reused against other document types.
> Forgive me but I have bought into the use of xsd:redefine and a 2 or 3 
> file method to create an adapter schema. One file is the original UBL 
> schema, one file is my new element definitions (in its own namespace) 
> and the third imports the two schemas making the actual restrictions and 
> extensions. The current examples would fit with this model, they would 
> just be put inside a redefine and the above methodology explained. I 
> have heard that redefine is not appreciated here and the use of xsi:type 
> leads me to think that I'm missing something as well.
> Could someone agree or disagree with the approach above. If you disagree 
> and have a different scenario in mind, please describe it and maybe 
> provide some reasons why the above doesn't work for UBL.
> Once I get help with the above, I can start looking in detail at the 
> current examples.
> General Questions
> 1) Are we allowed to define completely new documents in UBL or am I 
> always enhancing the existing ones? even if I'm using an incompatible 
> method?
> ..dan

Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |         1800 Harrison St. Oakland, CA 94612
W3C AC Rep / OASIS TAB Chair

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