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

[Tim McGrath <tmcgrath@portcomm.com.au>]

First of all, let me apologise for not following up on this as promised.

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.

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.

>
>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!!!! :-) )

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.

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.


Eve L. Maler wrote:

> The theory is that publishing markup will be needed at some point, and 
> the hope is that something like XHTML will be sufficient for that. 
> We're trying to find out if there are any known needs that would point 
> to a custom publishing markup solution rather than XHTML.  But we 
> definitely already have a principle that says non-semantic markup 
> should be avoided where possible.
>
>     Eve
>
> Lisa wrote:
>
>> Eve,
>> I have looked at the request for Publishing Markup and have some
>> thoughts on this.  First, do we really want to do this?  And second, if
>> we do, why don't we just use something that is already invented
>> somewhere?  As it is mentioned below use XHTML.
>>
>> So, in light of the first question, do we really want to do this?  I can
>> see the need within descriptions of items within catalogs, or other
>> general notes, that need to be marked up like this.  Since we are
>> talking "Ebusiness" this should mean it is a way to show the data on
>> screen, as in catalogs. 
>> Well, it looks like I could go along with this, as long as we know
>> exactly where we need this type of markup and keep it limited to these
>> areas.
>>
>> Lisa Seaburg
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142