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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-sbsc message

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