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: RosettaNet Comments


We received a comments document from RosettaNet that went through a
comparison and commenting of our NDRs.  We have broken them into sections
that go together for discussion purposes.  Each section is being sent out in
email. Please take the time to read through and comment back to the list.
Since we are so close to deadline, this is important that it get done as
soon as possible.  Thank you.




2.4.2 Rule RN 2

Rule: Order of xsd:schema attributes MUST be as follows: targetNamespace
declaration, declaration binding "xsd" namespace prefix, default namespace
declaration, declaration binding "tns" prefix, any other declarations
binding prefixes to other namespaces, elementFormDefault declaration,
attributeFormDefault declaration and version declaration"/>




Comment: Consistent placement / ordering of components helps with human
readability and debuggability of Schemas.







2.4.3 Rule RN 3

Rule: XML Schema built-in default values MUST be specified consistently.




Comment: Having mixed approach when indicating XML Schema built-in default
values, like sometimes indicating minOccurs="1" and sometimes not, is often
confusing for the human audience.







2.4.4 Rule RN 4

Rule: Schemas MUST follow consistent structuring rules.




Comment: Consistent placement / ordering of components helps with human
readability and debuggability of Schemas. RosettaNet uses the following
structuring rules.




Rule

  1.. Logically related constructs SHOULD be placed together in the same
file in order to support better abstraction, reusability and clarity.


  2.. Logically related constructs within the same file SHOULD be placed in
close proximity to promote understanding.


  3.. The documentation for a Schema SHOULD be placed just after the
top-level xs:schema element. The documentation for individual components as
listed above SHOULD be placed immediately after the component name
declaration / definition.


4. When not in violation of the previous rules, the following SHOULD be the
desired order of global Schema components.

Reusable global element(s),

Global element named groups,

Global reusable attributes,

Global attribute named groups,

Global simple types,

Global complex types with sequence content model,

Global complex types with choice content model,

All of these components are internally sorted alphabetically by names.







Ordering of components within Type definition

Rule

Within the type definition, the sequences, choice, groups and sub-content
models SHOULD be ordered in alphabetical order. Also within each content
model (like sequence, choice, groups etc) elements SHOULD be sorted in
alphabetical order. The only exception is in the order of attributes and
attribute groups. In element and type definitions, the attributes and
attribute groups SHOULD be listed alphabetically at the end, after the
content model and elements.




Rationale

This ordering scheme permits easy reading of Schemas for debugging purposes.







2.4.6 Rule RN 6

Rule: While creating names for inner elements, concatenating the name of the
inner element to the name of the outer element SHOULD be avoided. The
exception to this rule is the following: if the outer element name cannot be
prefixed with all inner element names sensibly, then each inner element name
SHOULD be created by concatenating the outer element name to it.




In the example below, both the elements Address and Phone would be sensible
as "ContactAddress" and "ContactPhone" - because of this, concatenating
Contact with the Address and Phone is avoided.




<complexType name="ContactType">

<complexContent>

<extension base="us:SomeBaseType">

<sequence>

<element name="Address" type="xyz:AddressType"/>

<element name="Phone" type="xyz:PhoneType"/>

</sequence>

</extension>

</complexContent>

</complexType>

<element name="Contact" type="ContactType">













++++++++++++++++++++++++++++++++++++++++++++++++++++
Lisa Seaburg
AEON Consulting
Website: http://www.aeon-llc.com
Email:  lseaburg@aeon-llc.com
Alternative Email: xcblgeek@yahoo.com
Phone: 662-562-7676
Cellphone: 662-501-7676

"If you obey all the rules, you miss all the fun."
                       -Katharine Hepburn
++++++++++++++++++++++++++++++++++++++++++++++++++++



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003
BEGIN:VCARD
VERSION:2.1
N:Seaburg;Lisa
FN:Lisa Seaburg (E-mail)
ORG:Aeon LLC
TEL;WORK;VOICE:(662) 562-7676
ADR;WORK:;;;Senatobia;MS;38668;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Senatobia, MS 38668=0D=0AUSA
URL;WORK:http://www.aeon-llc.com
EMAIL;PREF;INTERNET:lseaburg@aeon-llc.com
REV:20030924T221159Z
END:VCARD


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