[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]