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] outstanding tag structure issues


Dear all
forgive me for any multiple postings. My ISP is having a bad hair day and 
I am having problems sending mail.

In case you have not recieved this - here are a list of things we still 
need to sort on the tag structure and some comments for finalization....

-----------

(1) Naming Rules for Dictionary Full Names -
These are currently comprised of theobject class+property qualifier + 
property term + rep term. Property Term is removed if it is the same as 
the Representation Term.

For Discussion:
There should be a possiblity to use XPath here.

 


(3)Names of XML Constructs must not use non-alphabetic delimiters or use 
non-letter characters - we need to agree on this or ask for input from 
the LCSC. I can't see any reasons to reject this...

For Discussion:
What would be the language implications of this. Some translations might 
require punctuation of compounds for semantics reasons.

(4) Names for XML Constructs must use camel-case except DUNS - should 
they be enumerated lists or is there a more general rule?

For Discussion:
It depends if there are recognized lists of these used within the EDI 
community that we could use to create the enumerated lists. Generally, I 
would argue for a rule if there is a recognized standard (i.e."de facto") 
one that we can refer to. 

(5) Is there ar requirement to distinguish global attributes in terms of 
naming or declaration.

For Discussion:
Currently, I see no reason. All global attributes are defined in the 
attribute UidAttributeGroup. Currently, only uid, uidRef, uidRefs and 
xs:language are global

Mixed content elements are leaf elements with a Rep term of Prose - Prose 
not a current Rep term so we need to recommend this addition.  mixed 
contennt only for prod catalog


(6)No empty elements are permitted.

For Discussion:
Have we formally agreed this and can I put it in the new NDR Draft


(7)Rules governing elements of the same name and their respective types - 
what are the naming conventions?

For Discussion:
I am note sure what we intended with this.

The current recommendation is to utilise role-based naming of elements 
(as per Bill Burcham in his Modnamver paper for aggregates) and they use 
the name of the assigned type directly in the type name (for basic 
BIE's). For the purposes of naming LC SC distinguish between CCTs, reused 
complex types in the UBL Core Library, and complex types specific to a 
functional area.

- For elements with a type from the CCT package, the rule is:

   PropertyQualifier + PropertyTerm + CCT (but fold final two
   fields if equal)

e.g. BuyerAccountID

- For elements with a type either from the reused type package
(the UBL Library) or from a functional area package (e.g., the
Order module), the rule is:

- PropertyQualifier + PropertyTerm +RepTerm (for lower leaf)
e.g. LatitudeMeasure

(8) Mixed-content elements are considered to be leaf elements with a 
Representation Term of Prose. (Note: This rule is proposed, but has not 
yet been decided as a recommendation of the Naming and Design Rules SC.)

FOr Discussion:
We have not hitherto come across any examples for this. Suggest we let 
this open.



(9) Naming of simple types, and complex types that contain simple content 
differ from regular complex types -  are RTs used.

For Discussion:

A Core Component with simple content should be according to leaf rule - 
i.e. like 
Supplementary components (i.e. of the CCT) will be reprsented as 
attributes and function like leaf attributes

Eve - you had an example of this i think NameId???




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


Powered by eList eXpress LLC