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] | [Elist Home]


Subject: [ubl-ndrsc] issue summary: local vs global elements


As a start toward a position paper and recommendations for using local
vs global elements, I've begun a summary of issues and straw-man
recommendations for discussion during our Wednesday telecon.  I'll
format these in XHTML, but just want to get the ideas down to start (I
don't have an xhtml DTD and CSS configured in my XMetaL editor after
reinstalling a new version...).

ISSUES:

1. Validation.
        Can the current XML parsers validate using XSDL schemas with
local element definitions, especially when unqualified?

2. XSLT and unqualified local elements.
        I'm concerned that XSLT XPath expressions may have problems if
unqualifed local elements are used.  However, this might be an issue
only if the instance document uses a default namespace (i.e. no prefix
for some elements in the document).  For example, how will it handle
"ipo:purchaseOrder/shipTo"?  We don't have control over how instance
documents are written.

3. Extension, restriction, and other forms of schema customization and
reuse.
        As noted by Kelly, elements in a content model cannot have
their type modified unless they use local element defintions in the
base complexType.  (We need good example document fragments of these
alternatives.)
        What other schema customization approaches may encounter
problems with local elements, either qualified or unqualified?  Again,
we need examples of customizations based on experience from xCBL.

4. RELAX-NG validation of instances with unqualified local elements.
        If a document instance is written with unqualifed local
elements, can a RELAX-NG grammar be written that can validate the
instance?  Review the message I posted yesterday from xml-dev
discussion, where local elements have *no* namespace.  Need to review
current RNG draft specification.


OPTIONS Pro/Con:

1. See the meeting notes from last week for our matrix of
alternatives.  I'll roll these together later this week.


RECOMMENDATIONS:

1. elementFormDefault = 'unqualified'

2. Use local element definition whenever element type is a primitive
datatype (string, int, etc.)

3. Use local element definition if assigning a role name to another
element type (i.e., not just reusing a reference to the shared
element).  This approach is used frequently in xCBL SOX schemas, e.g.
in SOX, notice SellerParty and BuyerParty as local element names, but
simply embedding a reference to ChangeOrderNumber which is another
complex type included in this content model.

 <elementtype name="ChangeOrderHeader">
      <model>
           <sequence>
                <element type="ChangeOrderNumber"/>
                <element type="string" name="ChangeOrderSequence"/>
                <element type="datetime" name="ChangeOrderIssueDate"/>
                <element type="Reference" name="OrderReference"/>
                <element type="Party" name="SellerParty"/>
                <element type="Party" name="BuyerParty"/>

4. If a role-qualified element is used in several complexType
defintions (e.g. SellerParty is used elsewhere), we need a guideline
as to when the SellerParty element shoule be declared globally and
reused.  If reused more than one time?  More than five times?  Never
reuse these kinds of elements, but simply reuse their types (e.g.
Party) as is done in this example?




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


Powered by eList eXpress LLC