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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Re: [ubl-ndrsc] import versus include schema


Bill, 

Thanks.  SSM6, SSM7  have no inkling on the word "include"
at all.  I don't think it is fair to expect a read who
looks at the document first time round to know that 
SSM6 and SSM7 were "clearly" trying to forbid certain
configurations between uses of import and include.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Wed, 15 Oct 2003, Burcham, Bill wrote:

>>To Chee-Kai's issue #16 from today's discussion.  To the first note:
>>
>><!--  Note: it is not non-compliant with XML Schema spec to import the same
>>schema more than once, provided the semantic treatment result in exactly the
>>same as if the schema had been loaded the first time.  But we should rule
>>this more lenient (but not incorrect) spec out in UBL. -->
>>
>>It's true that the UBL rule is more restrictive than the XSD one.  It is
>>supposed to be.  The reason is this: UBL is comprised of components.  Each
>>component is directly usable (by a user external to UBL) by import of a root
>>schema for that component.  The component (root schema) itself includes any
>>necessary (internal) schemas -- and also imports other root schemas it
>>requires.  This frees the end-user from having to know the internal
>>structure and dependencies of the component.
>>
>>If two such root schemas (namespaces) are interdependent then they are not
>>really usable in isolation.  Therefore they essentially comprise one
>>component.  So if two components are interdependent UBL says they should be
>>combined into a single component.  This is simply for design cleanliness,
>>and clarity.
>>
>>To the second point:
>>
>><!--  Note 2: The two-level import restriction has turned out to be too
>>restrictive for implementation.  It needs to be relaxed.  An example wording
>>is proposed above.  -->
>>
>>We agreed on the call today to ask Chee-Kai for specifics here.  I don't
>>know what the real issue is here.
>>
>>-Bill
>>


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