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


Just catching up on my mail after XML 2002...  I think we need to 
discuss Gunther's latest experiments as soon as possible.

I'm inclined to believe that a UBL-specific vocabulary for embedded 
documentation is indeed more productive than the XHTML scheme we 
selected earlier.  After all, now even Mozilla supports in-browser XSLT 
transformation to HTML, so if we want this stuff to display in a pretty 
fashion, we can supply a stylesheet.  However, this means some rule 
changes and some markup design.  Maybe we can just rely on Gunther to do 
that design, but we need to change our rules explicitly.

Regarding the lack of global element declarations, we need to look at 
this very closely.  This is the first real test of the new decision, and 
if it doesn't hang together, we need to know why.  Perhaps Gunther can 
lead us through the script actions and see what the problem is; I'm not 
sure I fully understand from his description below.

	Eve

Stuhec, Gunther wrote:
> 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
> 

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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


Powered by eList eXpress LLC