OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-hisc message

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


Subject: Re: [ubl-hisc] Proposed XPath information instance


Ken

Hi

I think you're doing an excellent job of this. Sorry to have been
out of email reach over the weekend or I'll have added my 'ha'pence worth'
earlier.

I basically think we can leave all the TLA stuff until things reach maturity
and just carry on as you are for now. I don't like the idea of creating an
extension other than .xml for the xml detail file though.

Ultimately I'd like to see the detail file as a deliverable of the SBSC
- perhaps the normative deliverable of the SBS - so giving it a
separate name to the other files would suit that but that might be
out of scope for this discussion (and seems a bit cheeky since you're
doing this fine work as part of HISC, not SBSC). Just to say though
that I'd see it as highly reusable of course.

Must dash but enjoying how you are progressing this :-)

All the best

Steve


>>> "G. Ken Holman" <gkholman@CraneSoftwrights.com> 27/02/05 20:03:51 >>>
Okay I've just added attribute type information to the new XPath detail 
instance.  An example is below.

At 2005-02-26 21:41 -0500, I wrote:
>Now the question for the committee:  should I reflect cardinality in the 
>text and HTML presentations?
>...
>ACTION: please offer your opinion if I should leave text and HTML files 
>the way they are already, without cardinality, and just leave cardinality 
>in these new XPath files ... or should I add the visual indication of 
>cardinality into the text and HTML files?

I'm leaning towards "yes" on the above action.

Oh, note below that I've documented the vocabulary as a comment at the 
start of the detail instance.  I can easily replace the one-character names 
with more meaningful names, because the reports are short (totalling less 
than 300K) for all of the SBS subsets.  However, these eight reports for 
UBL CD2 total 17Mb in size, so I thought it important to be parsimonious 
... then I thought when the files are that big, who cares that they are bigger?

So I'm leaning towards changing the vocabulary names to be more 
verbose.  What do you think?

Next ... what to call these "detail" files.  The text file and the HTML 
file are obviously "XPath files" because the enumerate all of the possible 
XPath paths.  The XML instance file is an instance of the vocabulary that, 
while not valid, instantiates one of everything, every element and every 
attribute, without any other elements or attributes so is somewhat 
"pure".  We can call these "instance files".

The naming convention for the above three files follow: Order.txt, 
Order.htm, and Order.xml.

For now I'm calling the detail files along the lines of Order-xpath.xml ... 
but now we have two files using the XML extension ... which makes sense 
because they are both XML.  But, would it help if we called the file 
Order-detail.xml since there is only the raw material for an XPath file, 
not an enumeration of the XPaths themselves.  This instance is the 
intermediate instance used to produce the three other output files.  Until 
now I've not been publishing it, but it now has the cardinality and type 
information not found in the XPath reports.

The detail file has an "e" element (for an element) and child "a" elements 
(for attributes) in context of other "e" elements.  Lots of repetition, but 
once you navigate down to an element in context you can determine all of 
the information offered about that element without going 
anywhere.  Information on every element and attribute in every context is 
available in the file.  From this I produce the other reports.

Should we use a different extension and call the file "Order.???" so that 
we have four unique extensions?  Should we call it "Order-detail.xml" or 
"Order-xpath-detail.xml" as better names?

I'm not sure where I lean ... though I like the idea of four unique 
extensions, I hate to join the legions who have dreamed up new TLAs for 
XML-oriented vocabularies.  Anyone care for "XDI" for "XPath Detail 
Instance"?  "XPD" for "XPath Detail" See?  These don't really do it for 
me.  And, anyway, Google reveals that both TLAs are in use for XML 
vocabularies.  Perhaps by now all TLAs with an X are in use for XML somewhere.

Though I think it "proper" that ".xml" is suitable because it's how you use 
it, not what it says, I've been having file management issues moving files 
around when two types of files have the same extension.

Please offer your opinions on these simple housekeeping questions.  I don't 
want people to live with what I've decided if they can think of better ways 
to express concepts I'm trying to express.

Thanks!

.................... Ken

Z:\data\KenData\dev\xsd\UBL-1.0-SBS-0.5>head -50 xpaths\Order-xpath.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!--
Vocabulary: all names are one character in an effort to keep file size small


Attributes: p = prefix              Elements: e = element
             i = URI string                    a = attribute
             n = name                          t = text
             t = type
             m = minOccurs
             x = maxOccurs
             u = use (values: "o"="optional";"r"="required")
-->
<e n="Order" t="OrderType" p="po" 
i="urn:oasis:names:specification:ubl:schema:xsd:Order-1.0" m="1" x="1">
    <e n="BuyersID" t="udt:IdentifierType" p="po" m="0" x="1">
       <a n="identificationSchemeAgencyID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeAgencyName" u="o" t="xsd:string"/>
       <a n="identificationSchemeDataURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeName" u="o" t="xsd:string"/>
       <a n="identificationSchemeURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeVersionID" u="o" t="xsd:normalizedString"/>
       <t/>
    </e>
    <e n="SellersID" t="udt:IdentifierType" p="po" m="0" x="1">
       <a n="identificationSchemeAgencyID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeAgencyName" u="o" t="xsd:string"/>
       <a n="identificationSchemeDataURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeName" u="o" t="xsd:string"/>
       <a n="identificationSchemeURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeVersionID" u="o" t="xsd:normalizedString"/>
       <t/>
    </e>
    <e n="CopyIndicator" t="CopyIndicatorType" p="cbc" 
i="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" 
m="0" x="1">
       <t/>
    </e>
    <e n="GUID" t="udt:IdentifierType" p="po" m="0" x="1">
       <a n="identificationSchemeAgencyID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeAgencyName" u="o" t="xsd:string"/>
       <a n="identificationSchemeDataURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeID" u="o" t="xsd:normalizedString"/>
       <a n="identificationSchemeName" u="o" t="xsd:string"/>
       <a n="identificationSchemeURI" u="o" t="xsd:anyURI"/>
       <a n="identificationSchemeVersionID" u="o" t="xsd:normalizedString"/>
       <t/>
    </e>
    <e n="IssueDate" t="IssueDateType" p="cbc" 
i="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0" 
m="1" x="1">
       <t/>
    </e>

Z:\data\KenData\dev\xsd\UBL-1.0-SBS-0.5>

--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com 
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/ 
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc 
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal 



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