Pete,
I can live with that - now that I figured it out.
A corresponding hint would have saved my some time.
Maybe you guys are so much better with xml than I am :)
Norbert
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Zehler, Peter
Sent: Friday, February 14, 2014 11:32 AM
To: Semantic Model 3.0 Workgroup discussion list
Subject: Re: [SM3] CNXT MFD NS0214 Comment1: ##other versus ## any namespace
Norbert,
I did at one point use ##Any and the VendorExtension construct. I dropped ##Any due to nondeterministic schema issues with some XML parsers. (i.e., the parser has to look ahead to determine if the schema is valid.) I dropped the VendorExtension approach because it was decided that the PWG defines where PWG elements and attributes appear in the schema. If vendors wish to reuse the PWG elements they will have to either redefine the element in their namespace or wrap a vender extension sequence around the reused PWG element.
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: sm3-bounces at pwg.org [mailto:sm3-bounces at pwg.org] On Behalf Of Norbert Schade
Sent: Friday, February 14, 2014 11:08 AM
To: Semantic Model 3.0 Workgroup discussion list
Subject: [SM3] CNXT MFD NS0214 Comment1: ##other versus ## any namespace
There are many ways to follow a standard like PWG:
1. Study the specification (PDF document) and derive all your technical conditions from that while completely ignoring any xml schema.
2. Like '1.' but use the xml schema as a keyword reference.
3. Like '2.' but create real xml instances that are based on the xml schemas and incorporate the instances in your solution.
4. You may come up with other variations of the above.
Conexant follows path 3 to some degree.
We feel that any xml validation helps avoid quite a number of syntax and structural issues before you write any code. But that's our decision and not a template for others.
However that means that we indeed use the PWG schemas seriously.
That preamble may help understand why we will share 3 comments as our contribution to the SM3 effort.
Comment1 refers to xml namespaces.
In most if not all vendor extensions the PWG schemas allow elements to be added that are proprietary to the editor (e.g. Conexant).
Therefore you show '##other' as the namespace for those extensions.
That works fine.
However one cannot add any other PWG objects (defined in any included/imported PWG schemas).
While we are sure that has its reasons, we would not favor that.
Working with '##any' as the namespace for vendor extensions would allow flexibility while allowing people to reuse the elements that they have already used in other parts of the same xml instance, e.g. in the capabilities sections.
A simple example may be to refer to 'InputSource' (Platen/ADF) in Scan service descriptions.
I may want to use such an object in my vendor extensions. In my personal view I'd reference other PWG objects much more often than proprietary extensions.
One can workaround that problem with a little trick - and there are probably other ways to dodge the issue.
I've added a little sample schema that represents a Conexant specific extension with a 'isg' namespace.
You can find a VendorExtension element in there:
<xsd:element name="VendorExtension">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Note: an extension of namespace any must be the only element in the xsd:sequence.
Otherwise the schema becomes arbitrary.
This now gives me the requested framework in a xml instance to do something like this (just a small snippet):
<pwg:ScanServiceDescription>
<pwg:CharsetConfigured>utf-16</pwg:CharsetConfigured>
...
<pwg:VersionsSupported/>
<isg:VendorExtension>
<pwg:ServiceSpecificServiceDescription>
<pwg:JobConstraintsSupported>
<pwg:JobConstraint>
<pwg:ResolverName>PlatenMaxHeight</pwg:ResolverName>
...
I feel it would be more elegant to stay within the PWG namespace.
But there's always a way to get what you need.
Conclusion:
I am not requesting the PWG to change all namespace definitions of vendor extensions.
But I wanted to lay this design out with a proper technical background.
Regards
Norbert
Norbert Schade
Systems Engineer (printing)
Imaging Solutions
Conexant Systems, Inc.
201 Jones Road
Waltham, MA 02451
U.S.A.
Tel: 1-781-370-8929
Email: norbert.schade at conexant.com<mailto:norbert.schade at conexant.com>
Conexant E-mail Firewall (Conexant.Com) made the following annotations
---------------------------------------------------------------------
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
---------------------------------------------------------------------
_______________________________________________
sm3 mailing list
sm3 at pwg.orghttps://www.pwg.org/mailman/listinfo/sm3