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] UBL Schemas of: LCSC, EAN-UCC and ebXML CCSD Boeing Example



Hello all,

I attached a zip-file of XML-Schemas of our LCSC Library, EAN-UCC Example and ebXML CCSD Example. Could you review this schemas please, that I can change my perl script according your comments.

I made a new definition within in this schemas. Instead of the implicit XHTML tags for documentation, I use within the annotation elements in a specific namespace for the representation of all ebXML CCTS specific information. This elements looks like:

<xsd:annotation>
  <xsd:documentation>
    <ccts:ASBIE dictionaryEntryName="Contact_ Party. Address" definition="associates (optionally) the party with one or more addresses" qualifierTermObjectClassTerm="Contact" objectClassTerm="Party" propertyTerm="Address" representationTerm="Address" />
  </xsd:documentation>
</xsd:annotation>

This elements have in comparison to the XHTML tags the following examples:

- You can establish some queries (XML-Query and/or XPath) for searching of core components in a database much more easier. I installed a share-ware XML-database on my computer and I do some testings with this schemas and I have seen that it will be much more easier, if the necessary information,
which you are searching for, is in one element with attributes only. The attributes gives all necessary information about "terms", "definition", "context drivers" and "names". You can set some filtering arguments against this attributes very easy.

- It much more easier to write a XSLT-script for documentation, if this information in XML-specific format and not in XHTML-format within the XML Schema. Because, it might be much more clarity, if we put this information about terms etc. into a table. And a aggregate can have many child, which will
be represented in the same table. It is quite hard, to define this formating information about this table within the XML-Schema. But it is much more easier, to do this outside in the XSLT-Script especially.

My recommendation is that we do not any formatted or layout information into the schema of the UBL Library. It will be better if we handle this information completly outside (XSLT-Scripts) etc.

Furthermore, I do not use any global defined elements for ASBIE or BBIEs. Because the tagnames of the child within any aggregation do not have always the same name as the name of a global defined element. For example, if we use "Party.Identifier" within the aggregation "Party.Details" it is not
necessary that the Object Class of "Party.Identifier" will be represented as an element tag. Therefore, I generated "complexTypes" for each ABIE and BBIE only and the BBIEs and/or ASBIEs within a ABIE are derived from this complexType, but sometimes with another name. I guess, we have to define some
rules for that definition as soon as possible.

At last, I would like to say the representation doesn't based on the definition from Eve, now. The reason therefore is that I do not really know, how I can define the prefixes for the namespaces and the namespaces for the codelists itself. I guess, we should discuss about that as soon as possible,
too.

Kind regards,

     Gunther

Attachment: UBL_Schemas.zip
Description: Binary data



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


Powered by eList eXpress LLC