[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re:[ubl-sbsc]Groups-UBL-1.0-SBS-1.0-beta-2-in-progress-20050312(UBL-1-0-SmallBusinessSubset-1-0
Ken Now reading your posting at http://lists.oasis-open.org/archives/ubl/200503/msg00048.html I agree that the single id attribute in the root element should suffice since, as you point out, (the penny just dropped) we already have another attribute with the full namespace of the underlying document. Many thanks Steve >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 23/03/05 17:45:37 >>> Regarding the version of the subset, I'd think we could get confusion between the version of the subsetted UBL Schema and the SBS subset version if we concatenate them. I'd really prefer to see a separate attribute for the version of the subset (e.g. subsetVersion="1.0-cd") so that it is absolutely clear which version of UBL itself is being used (fairly essential for SBS use). Not that this would be essential in something like ebBPSS or ebMS where both the UBL Schema and the subset could be identified by their respective uri's in completely separate elements' content. But outside of such a standardised framework, e.g in an ad hoc trading partner agreement, it might leave room for ambiguity. After all it may be that there could be a future version of UBL called say 2.0:1.0. Really I'd see the NDR principle as being apllied to the UBL Schemas and our case being out of scope for this set of NDRs. Thinking of the word 'namespace' or 'identifier' I get the impression that namespace is the word used in ebBPSS and ebMS but I guess, after some verification of this, we could perhaps put a note in documentation to compare our identifying uri with what in such contexts might be termed a namespace. All the best and many thanks Ken. Steve >>> "G. Ken Holman" <gkholman@CraneSoftwrights.com> 23/03/05 17:15:22 >>> At 2005-03-23 16:36 +0000, Stephen Green wrote: >I was really thinking of something which might be >more tricky: Having a namespace for the >xpath-file schema is probably necessary but then >we also need a namespace, I believe, for every list >of XPaths (hopefully in XML, hence the relevance >of a namespace) for every UBL document type. I can accept the need for a unique identifier, and I like the idea of using a URI string, but I think it would be misleading to call it a namespace. I see URI strings as globally unique identifiers. I see XML Namespaces as one use of URI strings. But what you are doing here is merely identifying the SBSC vocabulary for a standardized UBL vocabulary using our small XML vocabulary identified by an XML namespace. Oh, did I say "merely"? >I'm thinking of a namespace, that is, not applied to >a W3C Schema as usual but applied to an XML instance >which functions like a schema. But that is just an identifier, not a namespace. I'm thinking of the parallel in XML where the DOCTYPE PUBLIC identifier identifies the DTD without stating anything about what the DTD expresses. >It would therefore >mean, I think, creating our own root element attribute >called namespace and having a uri as its value. Remember that we already have the combination of name= and uri= to identify the UBL vocabulary for which the SBSC subset is being expressed. >This is if we are going to have a set of files in XML which >each list the XPaths of the SBS of a UBL Document. >It is these files which I'm thinking would need the >namespace and possibly version attributes According to NDR 3.5 "UBL has decided to include versioning information as part of the document-id component of the namespace." ... this would imply to me that we would do the versioning solely in the URI of the identifier, rather than have both an identifier attribute and a version attribute. >for the >root element >e.g. ><(prefix):(root element name) >xmlns:(prefix)="urn:oasis:names:tc:ubl:sbsc:xpath" >namespace="urn:oasis:names:tc:ubl:sbs:xpath:Order-1.0" >version="1.0-beta-2"> So this would be a new document element above the existing "element" document element? <element name="Invoice" type="InvoiceType" prefix="in" uri="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0" minOccurs="1" maxOccurs="1"> I'm not keen on introducing a new document element above a single child element, but I'm willing to do it by accepting that others might find too much information in the document element, and that the document element rules for <element> would be different than that for descendent <element> elements. And, would we need to identify the UBL vocabulary that the XPath expression is identifying, or is that sufficient in the uri= attribute of the child element? So it could be: <xpath xmlns="urn:oasis:names:tc:ubl:sbsc:xpath" id="urn:oasis:names:specification:ubl:xpath:Invoice-1.0:1.0"> <element name="Invoice" type="InvoiceType" prefix="in" uri="urn:oasis:names:specification:ubl:schema:xsd:Invoice-1.0" minOccurs="1" maxOccurs="1"> ... In the above I'm saying: "urn:oasis:names:specification" - an OASIS specification "ubl" - for the UBL project "xpath" - for an expression of qualifying XPath addresses "Invoice-1.0" - for the UBL 1.0 Invoice "1.0" - version 1.0 of the XPath expression >We'd therefore still need a set of uri's and appropriate rulings >about them - one uri for the namespace of the Schema of >the xpaths lists and others for the xpaths list themselves. Yes, I agree ... and I'm composing a post to the UBL list accordingly. Thanks, Stephen, ................... Ken -- 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]