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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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


Subject: Another editorial topic of Core for today's call - normative special statements


Gents,

I would like to reduce two out of three (or more) requirements per component. Why? Claro, but on the grounds of what, wait:

Sample:

4.1.1 Component NsPrefixMapping

The NsPrefixMapping component defines the mapping of namespace URIs to namespace prefixes. This is required to evaluate XPath expression when using transport syntaxes that don’t support namespace.
Below follows a list of the sub-components that MAY be present within this component:
« The NamespaceURI element SHALL contain one instance of a URI. » [DSS-4.1.1-1].
« The NamespacePrefix element SHALL contain one instance of a string. » [DSS-4.1.1-2].

4.1.1.1 NsPrefixMapping – JSON Syntax
« The NsPrefixMappingType JSON object SHALL implement in JSON syntax the requirements defined in the NsPrefixMapping component. » [JDSS-4.1.1.1-1].

[ - - 8< - -]

4.1.1.2 NsPrefixMapping – XML Syntax
« The XML type NsPrefixMappingType SHALL implement the requirements defined in the NsPrefixMapping component. » [XDSS-4.1.1.2-1].

[ - - 8< - -]


In case someone thinks, that JDSS-4.1.1.1-1 and XDSS-4.1.1.2-1 are not redundant, it would be great, if he could enlighten me with that insight, otherwise I think this is more distracting, than focusing. Why? Well, because we have N (here N=2)
general semantic verifiable requirements and attaching per syntax another reference requirement on them, as if the syntax would not in any case have to comply with the defining underlying requirements appears weird to me.

So we could besides the usual linting / well-formed / valid tricks in conformance and per syntax simply generally list in one place the applicable requirement codes, and then only add specifics (e.g. in JSON where we have to somehow constrain the substructures needed to interoperably mimic the XML or generic concept of a richer structure.

Sounds right? Hope so - looking forward to meet you guys this evening and then to perform the hopefully last two passes over the document (and collect the matching schema files ;-)

All the best,
Stefan.


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