Re: [ubl-lcsc] Global attributes and publishing markup

["Eve L. Maler" <eve.maler@sun.com>]

Tim McGrath wrote:
> I would like to propose the issue of publishing markup be relegated to 
> low-priority (if not dropped over the edge).  I suspect that 
> 'presentation' is a feature of specific contexts of use and not part of 
> any core library.  In fact, even these contexts are probably so specific 
> as to make any form of common definition irrelevant.  Whilst there are 
> subtle relationships between publishing/presentation and content, its 
> probably too ambitious for us to address right now.

The issue is low-priority, and if you'd rather put it aside for now, we 
can certainly work with that input.  However, I would be really 
surprised if publishing markup could be totally done away with. 
Descriptive information that is provided solely/primarily in order to be 
read by a real human being has been identified by several domain experts 
as a feature of product catalogs and possibly other types of messages. 
We can be careful not to overuse it, but I bet we'll need it at some point.

And since publishing markup is a well-worn path in markup design, there 
are a couple of extremely well-known and well-supported standards (e.g. 
XHTML and DocBook) we could choose from if we needed it.  So the initial 
feeling on the part of many in the NDR group is that *if* it's needed, 
we're inclined to pick and existing schema module and simply hook it up...

> WRT to Gunther's suggestions for global attributes, this is a very 
> significant issue and one we should address immediately so that our next 
> generation of the Library accommodates these ideas.. 
> 
>> First, does your methodology account for identifying "common" 
>> properties such as these?  The spreadsheet would need to say (e.g., 
>> though a flag) that the property is truly global (that is, it must be 
>> applied to *all* object classes), and would need to provide a 
>> definition of the property that could safely be used identically in 
>> building all necessary documentation.
>>
> we dont have any concept of something being 'global'.  We do have a set 
> of hierarchical structures, one of which we call a 'document' that acts 
> as the root for many re-used components.  we could associate additional 
> meta-data with our structure definitions (the pink rows on our 
> spreadsheet).  This could be used apply these features to all elements 
> defined within the structure.  However, i am not sure that the 
> properties/metadata/attributes Gunther refers to are global in that 
> sense.   In fact, his paper refers these things as 'common' in that they 
> will appear for every element, this is not what i think of as 'global' - 
> ie. defined once and inheritted by every element.

Sorry, my use of "global" was probably unfortunate.  I didn't mean an 
item provided on a message-level element and applying to everything 
below; I meant an item that gets assigned, by design, as a property to 
every class.  I used the word "global" because a schema technique often 
used for these is to make them namespaced attributes, which are called 
"global attributes".

>> Second, can you please consider the four common properties proposed by 
>> Gunther and confirm whether you want them?  (That is, can you add them 
>> to your spreadsheet somehow if you want them, and reject them 
>> explicitly if not?)
> 
> The first question we need to resolve is where should XML Schema 
> specific meta-data reside? 
> Currently, most of these definitions are created in the conversion perl 
> script - not a good idea! 
> But, if we move these to our logical model, it means we no longer have a 
> purely logical model.  It becomes bound to the resultant XML Schema. 
> Well, we have already succumbed to syntax specific meta-data such as UBL 
> Name (aka Tagname), so why not confront the daemon and commit ourselves 
> to a specific XML definition syntax, i.e.. XML Schema?  Perhaps we dont 
> need to - we just need to separate the syntax dependant parts of our 
> meta-data (ie physical meta-data) from the logical ones.  It becomes a 
> documentation issue of being able to produce both logical and physical 
> model views of our library.  It is the physical model view that has the 
> meta-data necessary to build an XML Schema (by applying NDR design 
> rules).  For example, these rules could state to implement certain 
> meta-data as attributes.  (Note: Our logical view could be used (by 
> others) to produce other syntax specific implementations eg. RELAX or 
> EDIFACT!!!! :-) )

I think that binding-specific information, if carefully designed, can 
often be useful for more than just one syntax binding.  The tag name is 
a perfect example!  But in any case, if such information doesn't reside 
in the spreadsheet (or an associated spreadsheet), it must be applied by 
hand -- definitely not a good bargain!

> So my vote is to add any XML Schema specific meta-data into our current 
> spreadsheet, but documented in such a way as to maintain their special 
> status.

I agree.

> Now, as to the relevence of the attributes in question. I am not sure i 
> understand what is being proposed.  I have read Gunther's paper and even 
> braved the XML Schema and its Primer, but i am still unclear. 
> Firstly, I understood we are currently capturing a "uid", is that not 
> correct?  Or is the UID you are referring to at the element instance? In 
> other words is this "the UID for any PartNumber is 33773" or is it "the 
> UID for this specific occurrence of a PartNumber element is 33773 and 
> the next PartNumber occurrence in the document will have another UID"?  
> In other words, is this a schema level value or a document level one?
> 
> Either way, what are the values we would fnd in uidRef and uidRefs? 
> Given that we have re-used elements within structures and re-used 
> structures within structures, wouldn't the only sensible values be "the 
> UID of my parent in this instance" (uidRef) and "the UIDs of my 
> children" (uidRefs), and the latter would only apply to aggregate 
> structures.  These are not so much 'foreign keys' as linked list or 
> 'tree' pointers.  We dont need/cannot have foreign keys because we are 
> restricted to a hierarchical data structure - parentage tells us the 
> relatonships.  I am not sure what modelling problems Gunther perceives 
> beyond the obvious relational vs hierarchical one.
> 
> If I am correct in these assumption, then what purpose would these 
> uidRefs serve? Does they add value to parsing the document? What about 
> the maintenance of these values?  If these are schema level values, then 
> isn't it simply an automated process to build them into the schema when 
> it is generated from the model?  If  they are document level values, 
> then it is up to the applications involved to maintain them.
> 
> Finally, if we are to support other languages for tags, then it should 
> be at the element level anyway.  This supports the idea of a foreign 
> language context extending the library with new elements and their tags. 
> Perhaps we may want to define language globally  (ie at a root structure 
> fr a document) for convenience - but  lets hope we keep to the UBL 
> standard Oxford English as given to us by ebXML CC and NDR. 
> So, in summary.
> Yes I think we add these attribute type of things (XML specific 
> metadata) into our spreadsheet (but we dont care if they are implemented 
> as XML attributes or elements).  Yes, uid (we already have it?) and 
> language (why not)
> - but i dont know what we mean with uidRef and uidRefs.

To be honest, I have not a clue about the motivation behind these 
suggested common properties.  Gunther may want to jump in here and 
explain his thoughts, but if not, perhaps these four items can simply 
serve to get the conversation about common properties started, and not 
be taken as a literal suggestion.

Thanks for following up on these points,

	Eve
-- 
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com